CachedUpdates becarefull !

[Abaksoft]

Hello Friends,

 

CachedUpdate and Autocommit  are  two properties very important !

With unigui, we are talking about a hundred users connected at the same time.

 

In such  multi users environement,  if your CachedUpdate is False  (as by Default with IBDAC /Devart), 

any changes by others users, on a UniDBGrid will attack directly your physical DataBase !

And if you are on this record (80% by chance), you will get this error : Conflict Record.

 

Solution :

Make sure :

__________________

Autocommit := False;

CachedUpdate := True;

__________________

 

it tooks me 4 hours to track the pb !

 

Regards

 

[rencarnacion]

Excellent, Thanks 

[Farshad Mohajeri]

Thanks for pointing this out.

 

Actually this problem is available for all multi-user client-server database applications.

[itognet]

will attack directly your physical DataBase   

[eduardosuruagy]

I'm using ADO, do you have any settings I need to make in it?

[rencarnacion]

ADO can't use cachedupdate   Eduardo You won't have these problem 

[eduardosuruagy]

Ok

[IRWANTO82]

Hello Friends,

 

CachedUpdate and Autocommit  are  two properties very important !

With unigui, we are talking about a hundred users connected at the same time.

 

In such  multi users environement,  if your CachedUpdate is False  (as by Default with IBDAC /Devart), 

any changes by others users, on a UniDBGrid will attack directly your physical DataBase !

And if you are on this record (80% by chance), you will get this error : Conflict Record.

 

Solution :

Make sure :

__________________

Autocommit := False;

CachedUpdate := True;

__________________

 

it tooks me 4 hours to track the pb !

 

Regards

 

how you handle the row for edit?

 

use form for edit row if its important data,

and always use lastupdate field to compare data change by other user before post

 

`lastupdate` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,