Forums

When I activate a delta database on a test system, to some extent it does what I expect... persistent data updates via some forms are committed without exception and when I deactivate the delta database the updates are discarded.

But one form in particular, upon attempting to commit a transaction throws a 3037 exception, and this snippet of the jommsg log ...

2010/10/28 21:41:09.034 02e48-26c8 PDB: User applications are not allowed to update: F:/wtadmacsu/server/c_system/_rootdef.dat
2010/10/28 21:41:09.036 02e48-26c8 PDB: *** <davem> encountered database error: No write access to database file(3037) ***

... seems to indicate that it is attempting to update _rootdef.dat in the normal (read-only while in delta mode) database path rather than the deltadb directory. In fact, I notice there is no _rootdef.dat or _rootdef.dat.old file in the deltadb folder.

Any thoughts, suggestions please? I confess my ignorance... generally what types of objects would be persisted to _rootdef.dat upon a commitTransaction? Although I understand that changes to metadata files, _user*.dat, are not permitted in delta mode, I am trying to clarify whether changes to _rootdef.dat are also not allowed, unlike other runtime data files. If that makes sense.

Thanks for any help.

The _rootdef.dat file contains user persistent instances of RootSchema classes that are not schema entities; for example, shared instances of primitive arrays and OLE objects.
In Jade 6.3 the RootSchema default map file _userdef.dat has been renamed to _rootdef.dat so that it no longer shares the _user name prefix with user schema files.
Please see the release information document for the Jade 6.3 release for further information regarding this file and its usage.
In regard to the exception you describe, I suggest that you open a contact in Parsys for this matter to be investigated by Jade Support.

Cheers, thanks 0.0.

The issue David has reported here is a previously unknown problem in the JADE kernel. JADE par #55182 has been opened to address the issue.
There isn't any solution at this time except to avoid updating objects that are mapped to the _rootdef.dat map file.

Regards,