Par2: Temp Tables 2000-03-01 -- Scott Ferret An industrial myth has evolved over the last few years in the
Clarion/SQL community regarding the need of a temporary table on the
server so that you can issue SELECT statements from anywhere and have
something to put in it. This article will try and put that myth to
rest (I know it is a futile exercise, but lets try).
I believe that the reason people believe that they have to have this
temp table on the server is they look at a Clarion FILE definition and
believe that there must be an equivalent TABLE to match it on the
server. You do not need this.
What the Clarion system requires is that the fields in the FILE
definition match some fields in some table on the server. This is so
it can get field type information from the server. The most important
thing to realise is that the fields on the server do not have to be
different fields. Here is a Clarion FILE definition that works with
SQLAnywhere with a user who has sufficient priority to see the system
tables. The idea can be adapted to work with any tables that you now
that your program will be able to see.
MyTempTable FILE,DRIVER('SQLAnywhere'),NAME('SysColumns')
Record RECORD
ALongField LONG,NAME('Length')
AShortField USHORT, NAME('SysLength')
AStringField STRING(100),NAME('cname')
LongField2 LONG,NAME('Length')
StrFld2 STRING(20),NAME('cname')
CStrFld CSTRING(50),NAME('cname')
END
END
The important things to notice are:
1) The file's label has nothing to do with the name of the table on
the server
2) The field's label has nothing to do with the name of the column
on the server
3) You can use the NAME attribute on a field to have multiple
fields point at the same column
4) You should try and use the same data types as the ones on
the backend. But it is not necessary.
Printed May 2, 2024, 2:21 pm This article has been viewed/printed 35109 times. |