Мимопроходящийесли есть полноценные READ COMMITED транзакции,
то к чему эти телодвижения с fix ? может немного надуманно, но
fix all; // начинаем длинный отчёт
create global temporary table _REPTAB(name char(20), val double);
insert into _REPTAB
select 'параметр 1', sum(some_val1) from TAB where p=1;
// В этот момент другой делает update TAB set p=2 where p=1;
insert into _REPTAB
select 'параметр 2', sum(some_val2) from TAB where p=2;
вторая строка без
fix table TAB;
не учтёт внесённое изменение и даст верный на момент начала отчёта результат.

плевать нам на другого, пока он не закоммитился.
или я чего-то не понимаю? Он закоммитился, а мы ещё не закончили считать. Поскольку записи отчёта не должны быть сформированы на основании различных состояний таблицы, то мы, не делая fix, можем (должны) игнорировать изменения.
Небольшое примечание к тому скрипту: в HT, если транзакция не объявлена явно (begin work), то по окончанию выполнения оператора update/delete/insert commit выполняется автоматически. Если в update/delete/insert обрабатывается группа записей, то изменения будут доступны по окончанию операции - как и положено.

2Мимопроходящий.
почти.
В HT первое же обращение к таблице создаёт её snapshot. Он существует в контексте пользователя и, далее, сохраняется в курсоре. То есть, если пользователь просматривает несколько результатов одного и того же запроса, то они могут различаться. Для курсора существует операция touch - приведение записей результата к текущему состоянию, но она довольно лукавая, поскольку не учитывает критериев отбора .
Чтобы сбросить snapshot, закреплённый за текущим курсором (и сессией), используется fix.
Для того, чтобы сделать snapshot по одной или нескольким таблицам принудительно, используется htMakePhoto.

Чтобы предупредить вопрос про курсор - тут есть свои особенности:
в курсоре выполняется sql-скрипт, состоящий из одного или нескольких операторов, включая процедурные. То есть, скрипт может выглядеть как-то так

var dt, val, par=2;
fix all;
select @dt = max(some_date), @val=sum(sum_val) from TAB1 where p = @par;
if (lastsqlerr()!=0) quit;
update TAB2 set dt=@dt where p = @par;
insert into TAB3 values(@par,@val);

select a.p, a.dt, b.sum from TAB2 a, TAB3 b where a.p=b.p;

если не поставить fix all; то будет использовано текщее состояние таблиц сессии (или создано новое, если это первое обращение к таблице).

ХайТехCколько одновременно активных пользователей поддерживает Хайтек на практике? Практически бывало до семи сотен. Но одновременно выполяющихся запросов при этом значительно меньше - ведь оператор в основном должен кнопки нажимать, а не сервера ждать.
Предположим есть что-то типа 1 Xeon 3040 (Core 2 Duo), 2Gb ram ,пару дисков в зеркальном рейде ,win 2k3. Сколько одновренно инсертящих выдержит такая конфигурация -- по какому закону будет деграивроать перформанс и с чем это будет связано (т.е. как оно там работает внутри)? Таблицы HyTech состоят из постоянной части и журнала изменений. Проиндексирована только постоянная часть, поиск же в журнале изменений ведётся практически перебором. Следствие: количество индексов не влияет на операции корректировки БД, но с ростом журнала изменений работа замедляется. Однако, последнее не так страшно, как могло бы показаться, поскольку доля изменений в общем объёме БД обычно невелика. Перенос журнала изменений в постоянную часть является отдельной операцией и выполняется, обычно, в нерабочее время по регламенту.
Мешают ли инсерты селектам Незначительно. Они пересекаются лишь на чтении заголовка журнала изменений, которое для select выполняется один раз в начале поиска.
-- ну вернее наоброт мешают ли тяжелые долгие селекты(для отчетов) инсертам. Как это проявляется и как реализовано это на самом деле? Мешают так же, как мешает копирование большого (размером с объём промежуточных временных файлов) файла. Ну и плюс свою часть процессора отчёт возьмёт. А вообще пакетные операции в Hytech реализованы весьма эффективно и, скорее всего, закладываться на многочасовые, даже многоминутные, отчёты излишне.
По какой лицензии распространяется хайтеч - доступен ли соурс?Вроде бесплатно, без исходников.

QПеренос журнала изменений в постоянную часть является отдельной операцией и выполняется, обычно, в нерабочее время по регламенту.

Сколь это трудоемко. Если это например раз в час делать - насколько база для пользователей закроется?Даже для очень интенсивно используемых БД это не делается чаще раза в день. Раз в час - бессмысленно. Если, конечно, не выполнялись нештатные запросы, модифицирующие полностью или большей частью таблицы размером в сотни мегабайт.

А какой предел у хайтеча. Работа с базой в 10 миллионов записей - ну пусть 10 таких таблиц и еще таблиц 30-50 мелочи(справочники) где-то 15-20 активных пользователей это реально? какое примерно железо нужно?
Вашей конфигурации должно хватить. Вообще желательно иметь объём памяти, достаточный для кеширования основных индексов - считайте приблизительно как кол-во записей умноженное на длину ключа+4.
И всё от запросов зависит - не нужно особо большой таблицы, чтобы написать что-нибудь, что отнимет 100% времени или забъёт диск. Это всего касается. Посмотрите свои типичные запросы на тестовой БД. Главное старайтесь всё сформулировать в одном sql-запросе - он в HT не ограничен одним sql-предложением, - избегайте перебора, чтения записей на клиента для обработки. Для расшифровки справочников используйте "кодификаторы" - посмотрите раздел "Встроенные SQL-функции", "Функции работы с кодификаторами". Это позволит избежать избыточных джоинов и существенно сократит время выполнения.

Про кодификаторы, наверное, лучше посмотреть в файле помощи "основные понятия и действия", "кодификаторы".