Tokay

Maybe UniServerModule>ServerLimits>SessionRestrict can help you?

да, так и есть. видимо я случайно серверный таймер использовал. с TUniTimer всё отлично работает!

fix

fix.

С TUniTimer всё должно работать.

топикстартеру: что именно вызывает затруднение? послать файл юзеру можно, например, с помощью UniSession.SendFile. прямо из потока, правда, не получится. но можно сделать какой-то флаг, что файл для посылки готов, его проверять по юзерскому таймеру (TUniTimer), и как файл 'созрел', кинуть его юзеру.

I have opened the bug in tracker, and waiting for fixing: http://jira.fmsoft.net/servicedesk/customer/portal/4/FSD-726 as a temporary solution you can hide the button and do refresh with external control.

Maybe tools like Eurekalog can help you.

Nicely!

All this functions are thread safe afaik.

Okay, here's this module. Usage, forms, pas: procedure TUniForm14.UniFormClose(Sender: TObject; var Action: TCloseAction); begin JvFormStorage1.StoredValues.Values['Form14Width'].Value := Width; JvFormStorage1.StoredValues.Values['Form14Height'].Value := Height; SaveGridLayout; JvFormStorage1.SaveFormPlacement; end; procedure TUniForm14.UniFormCreate(Sender: TObject); begin JvFormStorage1.AppStorage := UniMainModule.AppRegistryStorage; JvFormStorage1.RestoreFormPlacement; Width := JvFormStorage1.StoredValues.Values['Form14Width'].Value; Height := JvFormStorage1.StoredValues.Values['Form14Height'].Value; LoadGridLayout; end; procedure TUniForm14.SaveGridLayout; var SaveLayout: TUniGridLayOut; begin SaveLayout := TUniGridLayOut.Create(nil); try SaveLayout.SaveLayout(JvFormStorage1, UniDBGrid1, 'Form14Grid1'); SaveLayout.SaveLayout(JvFormStorage1, UniDBGrid2, 'Form14Grid2'); finally FreeAndNil(SaveLayout); end; end; procedure TUniForm14.LoadGridLayout; var LoadLayout: TUniGridLayOut; begin LoadLayout := TUniGridLayOut.Create(nil); try LoadLayout.LoadLayout(JvFormStorage1, UniDBGrid1, 'Form14Grid1'); LoadLayout.LoadLayout(JvFormStorage1, UniDBGrid2, 'Form14Grid2'); finally FreeAndNil(LoadLayout); end; end; DFM: object JvFormStorage1: TJvFormStorage Active = False AppStoragePath = 'Form14Placement\' Options = [] StoredValues = < item Name = 'Form14Width' Value = 943 end item Name = 'Form14Height' Value = 688 end> Left = 559 Top = 164 end Usage, the MainModule, pas: procedure TUniMainModule.UniGUIMainModuleBeforeLogin(Sender: TObject; var Handled: boolean); begin if Handled then begin ..... AppRegistryStorage.Root := AppRegistryStorage.Root + '\' + UniMainModule.LoggedUserUID; end; end; DFM: object AppRegistryStorage: TJvAppRegistryStorage StorageOptions.BooleanStringTrueValues = 'TRUE, YES, Y' StorageOptions.BooleanStringFalseValues = 'FALSE, NO, N' Root = 'Software\ACME Software\UniGuiStorage' SubStorages = <> Left = 504 Top = 216 end SaveUniGrid.pas

I have wrote such a class. But it has the dependence of the JVCL library. I don't know, is it good idea to piblish it. It can save and restore Width, Index, Visible and Expanded properties of each column in a TUniDBGrid. On the server side, store by user, in registry, db, xml or ini file.

Да, о нем. Насколько я понял идею - то процессы запускаются на разных машинах. Иначе не имеет смысла

Надежнее проверять на 10-20 юзеров, так как есть какое-то общее потребление ресурсов (памяти, и т п) а есть по-юзерно. На множестве юзеров будет точнее видно. Можно поставить балансировщик (HyperServer), посмотреть как пойдет на 2-3 машинах и докидывать их по мере надобности. Опять же - можно и памяти в одну добавить, если процессорного ресурса хватает. 32мя гигами оперативки на сервере мало кого сейчас можно удивить. Я частично связан с машинным обучением, там, бывает, вообще по 100+ гиг бывает нужно Что тут про 32 говорить.

он предназначен именно для балансировки на несколько машин, всё верно. на такое количество пользователей скорее всего придется несколько ставить.