Hi Thomas:

>Is this a compiler pragma changeble in mid-code (like a #define set in code) or
> something set globally before a build ?
It will be a global switch actually. You just mark the checkbox in the Compiler Project Form. I know there are some advantages to make it a #pragma, but we have not pragmas yet.

With regards to the tables.
You can match your table types to any interface provided that at least one of the fields in the table could match to the interface. The types has not to be exactly the same just compatibles. You will use this syntax:

TLOCAL myTable as SomeInterface
myTable = GetTableInterface([eSomeAlias],typeof(SomeInterface))
It automatically generates on the fly an interface to match SomeInterface. The order of fields is irrelevant.

It does not create a struct with offset. Instead when you Request the interface on an USED table it matches the interface / class to the current table layout. If you alter the table it automatically invalidates the cache of matched interfaces. So you can add / remove fields after compilation and your code likely will work if you did not make an incompatible change. Of course if you removed a field and then run your code without recompiling:

? MyTable.MyRemovedField && it will blow away.

This gives a huge speed improvement because the runtime does not has to lookup for every field access or aliased field access, the interface goes right to the field buffer. And has the nice thing that you can:

MyTable.SomeField = eValue

That is lot faster and less verbose than
REPLACE MyAlias.SomeField WITH eValue

And you don't get bite with REPLACE not working because the current alias, different to MyAlias, is EOF()





>Hi Samuel,
>
>just typing as I am thinking on this...
>
>Is this a compiler pragma changeble in mid-code (like a #define set in code) or something set globally before a build ?
>
>

>>TLOCAL myTable as SomeDatabase::SomeTableOrView
>myTable = GetTableInterface([eSomeAlias])
>>? MyTable.MynField  && Ok it exists
>>? MyTable.MyNotExistsField && Error at compile time, this field does not exists
>>

>
>Would this not break on some altjavascript:MessageSubmit()
[Save this message so it will appear for other members immediately] er table allowed today or make the code potentially unsafe against "simple" table exchanges keeping the field types but adding fields "in front" ? This assumes that GetTableInterface([eSomeAlias]) creates a struct with the field offsets of the table header at compile time, but any changes could blow that "assumption". Otherwise I how do you get the speed difference if you still interpret the header as it currently is ?
>
>curious
>
>thomas