How to know Table Memory used up

Vineeth.R

Hi All,

I know there is a memory limitation (i think 4mb) in adding fields to a table, how can we know how much of the space is used up in a table. Is there any shortcut way other than summing up for each fields one by one.

Thanks
Vineeth

AdrianAkers

Normally I wait until I have a problem with a table size and then start to panic! #-o

To be honest if the tables are going above 4MB I'd start to look to see if they have been normalised properly...

matteo_montanari

Vineeth.R wrote:

Hi All,

I know there is a memory limitation (i think 4mb) in adding fields to a table, how can we know how much of the space is used up in a table. Is there any shortcut way other than summing up for each fields one by one.

Thanks
Vineeth

Hi

The field table limit is 4Kbyte (4000Bytes for precision...).
So a "code 20" is 20 bytes

You can use the "Field" virtual table and filter for your table.
Skip disabled fields, flowfields and flowfilters and sum the "len" field.

Bye

Matteo

Vineeth.R

Hi Matteo,

Thanks, the field table can help but for big tables its difficult to go and look for how many flowfields are there in it to skip. Any other easier way to calculate the table memory or to skip the flowfields and calculate the rest of the fields.

matteo_montanari

Vineeth.R wrote:

Hi Matteo,

Thanks, the field table can help but for big tables its difficult to go and look for how many flowfields are there in it to skip. Any other easier way to calculate the table memory or to skip the flowfields and calculate the rest of the fields.

Difficult??? :?

Local variable "Field" of type rec and subtype Field

GetTableDefinitionSize(TableID : Integer) result : Integer
Field.SETRANGE(TableNo, TableID);
Field.SETRANGE(Class, Field.Class::normal);
Field.SETRANGE(Enabled,TRUE);
IF Field.FINDSET THEN
  REPEAT
    result += Field.Len;
  UNTIL Field.NEXT = 0;

do you need the "table definition size" or the size of the table on database?

Local variable "TableInformation" of type rec and subtype "Table Information"

GetTableSize(TableID : Integer;Company : Text[30]) : Integer
IF TableInformation.GET(Company, TableID) THEN
  EXIT(TableInformation."Size (KB)");

bye

matteo

David_Singleton

@Matteo, your math is wrong. Its more complex than that to calculate how much pace a field uses. I have posted numerous times with the formulas.

@Vineeth, you should never reach the limit. If you even get close to it it means that you have a badly designed system that needs to be redesigned and done properly. Even if you work out the maximum and use all that up, then you are pretty much guaranteed that you wont ever be able to do an upgrade.

Re-look at the code you have written and redo it.

matteo_montanari

David Singleton wrote:

@Matteo, your math is wrong. Its more complex than that to calculate how much pace a field uses. I have posted numerous times with the formulas.

@Vineeth, you should never reach the limit. If you even get close to it it means that you have a badly designed system that needs to be redesigned and done properly. Even if you work out the maximum and use all that up, then you are pretty much guaranteed that you wont ever be able to do an upgrade.

Re-look at the code you have written and redo it.

Hi david

mmm

i found this thread

viewtopic.php?f=23&t=27973&hilit=field+size

very interesting!

but... Decimal on c/side database is 12 Bytes but reading
http://msdn.microsoft.com/en-us/library/ms187746.aspx
Decimal (38,20) is 17 Bytes

Sql Server page/cluster limit si 8Kbytes (nav reduce this to 4kbyte for compatibility with C/Side database via FBK)... but the table definition size can change its size depending of database engine...

Nav assume that his masimum4kByte record will be correctly stored on SQL because the SQL Page size is 8Kbyte and then 12Bytes or 17 Bytes isn't a problem?

Thank you

Matteo

David_Singleton

As I said it is all irrelevant anyway. The correct thing to do is to fix the errors in the design of the database, not keep working around them.

matteo_montanari

David Singleton wrote:

As I said it is all irrelevant anyway. The correct thing to do is to fix the errors in the design of the database, not keep working around them.

i completly agree with you:

My last question was more "academic" than resolve the problem signaled by Vineeth (already resolved by your post).

Bye

Matteo

matteo_montanari

.

AdrianAkers

Oh... So similar to what I said...

To be honest if the tables are going above 4MB I'd start to look to see if they have been normalised properly...

David_Singleton

AdrianAkers wrote:

Oh... So similar to what I said...

To be honest if the tables are going above 4MB I'd start to look to see if they have been normalised properly...

yep :thumbsup: