A little curiosity of mine is around this finding & why it is so…
Fill the item description field of an item in dynamics GP and then paste the text into a notepad application to measure its length. You will find it has a capacity of one hundred characters…
Yet have a look at the database, it has a field size of 101…
but look, the UI is limiting the keyable length to 100…
So there is an “extra” inaccessible character in the descriptions that you cannot use? What secret confidential information do you keep in your extra description extra character?
[Edit 2017/08/08] David in the comments explains this for us as:
Every string field of even length will have an extra character at the database level.
This is a Dexterity feature from legacy behaviour.
Before SQL was used as the database, Ctree and Btrieve was used. They performed better when each record in a table was a multiple of 16 bits, 2 bytes, as the early x86 processors were 16 bit.
To ensure this string fields were padded to make the storage length an even number. Strings require the number of characters in the string plus a length byte when stored and so can be 0-255 characters long.
On your screenshot, the keyable length is 100, plus a storage byte = 101, plus pad to even gives 102 with an extra hidden character.
Odd length strings don't need padding to be an even total size.
First we should define what a table heap is. A heap is a table without a clustered index.
Data is stored in the heap without specifying an order. Usually data is initially stored in the order in which is the rows are inserted into the table, but the Database Engine can move data around in the heap to store the rows efficiently; so the data order cannot be predicted.
There are sometimes good reasons to leave a table as a heap instead of creating a clustered index, but using heaps effectively is an advanced skill. Most tables should have a carefully chosen clustered index unless a good reason exists for leaving the table as a heap.
Generally I would say we are more used to finding a clustered index on a table, but looking below you can see the more normal picture for the indexes of a GP table.
Microsoft Dynamics GP does not use many clustered indexes in its database.
If you read The Microsoft Dynamics® GP Architecture White Paper, then it would seem to be a decision based on research and data:
So which tables? Lets look for tables in the SOP series that have clustered indexes on them:
t.name AS table_name,
I.type_desc AS index_type,
I.is_unique AS is_unique_index
FROM sys.tables AS t
INNER JOIN sys.schemas AS s
ON t.schema_id = s.schema_id
INNER JOIN sys.indexes AS I
ON t.object_id = I.object_id
WHERE I.type_desc = 'CLUSTERED'
and t.name like 'Sop%'
order by 1;
Interesting is that only seven of the SOP tables that have clustered indexes, the rest are heaps. So large tables such as SOP30300, that is particularly large, a 8GB table in one of the companies I work with, are a heap. This at first glance seems wrong. in fact the MS advice from Heaps (Tables without Clustered Indexes) is
Do not use a heap when there are no non-clustered indexes and the table is large. In a heap, all rows of the heap must be read to find any row.
I do wonder about the conditions under which the decisions to not use clustered indexes was made, but have to trust the research was accurate.
So the reason? GP didn’t always run on SQL server, it was on ISAM in the old days. The database schema that GP uses owes a lot to that legacy and is the reason for many of the oddities and areas lacking in GP’s use of SQL server and I expect this use of heap tables is also from that legacy and that study showed there were no performance benefits from introducing a clustered index.
In Dynamics GP development, we have lots of .dll files around arising from support for many version releases of GP. These files litter our projects and sometimes a dll may go astray and cause trouble by ending up in a folder to which it should not belong.
This powershell command is a quick way to look for all the versions of a .NET assembly (dll) version within a folder tree.
Get-ChildItem -Filter Microsoft.Dexterity.Bridge.dll -Recurse | Select-Object -ExpandProperty VersionInfo | Out-String -Width 180
ref: Stackoverflow Get file version and assembly version of DLL files in the current directory and all sub directories
The versions can be seen on the left and any offending .dll files that are not in the correct directory for their actual version number can be quickly and easily identified.
This avoids getting into <assemblyBinding> redirects when dealing with the error at compile time of
Found conflicts between different versions of the same dependent assembly