Temporary table occupation

David_Singleton

One big advantage of using a custom "template" table rather than an existing table is that you can remove all the keys that you don't need. Most hot tables in Navision, the keys use more space than the actual data, so you can generally make the record at least 1/2 the size this can be a big difference for very big tables.

Belias

and if you just read the REAL table to populate your temporary table variable, you are not going to lock the real table.
Summary:
- don't use locktable before looping your REAL table variable (and i wonder why anyone would do it )
- don't use TRUE parameters of FINSET instruction on your REAL table variable
- don't use MODIFY,INSERT,DELETE on your REAL table variable, but feel free to use them how many times you like it on your temporary variable, because

The whole process of working with temp table is working in Native DBMS (like when working with native DB) and is done locally on the client. No connection with anything on SQL...

One big advantage of using a custom "template" table rather than an existing table is that you can remove all the keys that you don't need. Most hot tables in Navision, the keys use more space than the actual data, so you can generally make the record at least 1/2 the size this can be a big difference for very big tables.

To avoid this, i unmaintain the SQLIndex on the keys that are used only by the "temporary instances" of the real table

David_Singleton

Belias wrote:

David Singleton wrote:

using a custom "template" table rather than an existing table is that you can remove all the keys that you don't need. Most hot tables in Navision, the keys use more space than the actual data, so you can generally make the record at least 1/2 the size this can be a big difference for very big tables.

To avoid this, i unmaintain the SQLIndex on the keys that are used only by the "temporary instances" of the real table

Then you probably don't understand TempTables .

TempTables are based on CSIDE principles, so even if you disable the SFIT and SQL maintenance, then when you create as a temp table they will still use memory to create and store those Indexes.

Belias

...the keys use more space than the actual data...

I thought you were talking about indexes in SQL, and I didn't read carefully the rest of your post, sorry :whistle:
anyway, i think that if a temporary table gets SO big to be a problem, you probably need to rethink the process/data structure, but this is another story.

David_Singleton

Belias wrote:

i think that if a temporary table gets SO big to be a problem, you probably need to rethink the process/data structure,

:thumbsup: Yes I agree, and that is probably the case here.