We experience strange things sometimes that are unexplainable. For example: Sometimes we have tables that we delete using delete_table or the database manager and the table is gone from everywhere except the application manager. And there is no way to get rid of it besides deleting all the records from the SYSREPOSIX and then running rebuild system Indexes. Many other things happen and we wonder if it is a result of having a DBT file over 64k.

What are all the ramifications of having a DBT over 64k? And when can we count on a fix?

Not sure about the size problem, but when we have had corrupted DBT files the best solution is to delete the DBT file and copy the SYSPROG.DBT to the application.DBT and then re-add all the database tables and then save the database.

Works wonderfully well.

We have found is resolves lots of problems.

Colin,

We have found is resolves lots of problems.

Well I have lots of problems!

Like what problems does it cure, please?

- Oystein -

Jeff,

What are all the ramifications of having a DBT over 64k?

Assuming it is not SYSPROG.DBT, I do not know of any issues with a DBT over 64k.

It is possible to have a DBT which is not correct; this typically happens when you create/delete tables without saving the database definition.

Cameron Purdy

[email protected]

I was told by tech support that there are known problems with a DBT over 64k and that they were supposed to be fixed in the 3.7 release. Tech support said database manager did not work properly and I understood it that there were other issues as well. We did have trouble with database manager not working. However, that seemed to clear up when we cleared the SYSREPOSIX and Rebuilt System Indexes. I was just following up on that and trying to understand what other issues there are.

Jeff,

There may be limitations in the Database Manager which are related to the number of tables/volumes or the total size of the list of tables/volumes. Some of those limitations may be related to the data itself (transfering lists of information from the engine to the Database Manager) and some of those limitations may be related to the display of the data (for example, the hierarchical table view area of the Database Manager).

There is a limit on the size of the table/volume information, since the table information is stored in @tables and the volume information in @volumes. (What you see in SYSVOLUMES is just a view of the information in @volumes, similarly SYSTABLES and @tables.) For example, the table names as attached are stored in @tables(0) delimited by @fm, so the list of tables cannot exceed 64k.

Commands such as Attach_Table, Detach_Table, etc. work against @tables and @volumes; this is referred to as the "memory resident database", which is all of the information known to the current session about the attached volumes and tables.

When you save the database definition (Define_Database), the information from @tables, @volumes, and the list of known file systems (sc_afsnames) are assembled as a "database template" structure, which you know as a .DBT file residing in your OpenInsight directory. For SYSPROG, this information is loaded into @tables and @volumes by RTP1 (oengine boot) which does not handle ]64k .DBT files; note that the engine always loads the SYSPROG database when it boots, since it uses that database to get information about security and about other applications/databases. For all other apps the .DBT is loaded by the Swap_Database routine, which does handle ]64k .DBT files.

So, in summary, no tools work directly against the .DBT file, but the tools may have limitations that are reached not coincidentally when the size of the .DBT file gets very large since the memory resident database which the tools operate against comes from the .DBT file. The routines that create and update the .DBT are (1) Define_Database and database synchronization routines, (2) various parts of the RDK, and (3) internal routines used during OpenInsight upgrades. The routines that use the .DBT files are RTP1 and Swap_Database.

Cameron Purdy

[email protected]

Thank you for explaining in more detail. We have roughly 600 tables which translates to 1200 because of dictionaries. Our system will continue to increase as we are still in development of some of the modules. Do you know the average size of one table entry in @tables or where the limit is on @tables?

Tech support said there are some issues relating to this that are being worked on for 3.7. Is this true and if so what is being done?

As the information in @Tables varies on how you drive .. mileage may vary from that advertized.

@Tables is a dim var (0-5) and so you could write a simple routine to look at the sizes of each dim.

Break into the debuger and look at system variables ..

dsig

David Tod Sigafoos ~ SigSOlutions

[email protected] cis:70302,77 voice:503-639-8080

View this thread on the forum...