Rick Martin's template to add all fields to a view
This template is handy for TPS to SQL conversions where you are not sure all the fields actually used in the procedure got added to the hot fields.
UP_SQL_ProjectAllFields.tpw
#EXTENSION (SQLProjectALLFieldsBrowse, 'Project all fields in view tables for SQL Browse'),REQ(BrowseBox(ABC))
#!
#ATSTART
#FIX(%File,%Primary)
#INSERT(%SQLProjectALLFields)
#FOR(%Secondary)
#FIX(%File,%Secondary)
#INSERT(%SQLProjectALLFields)
#ENDFOR
#ENDAT
#!
#GROUP(%SQLProjectALLFields)
#FOR(%Field)
#SET(%ValueConstruct,%Field)
#INSERT(%CleanDimensions(ABC))
#IF(~INLIST(%ValueConstruct,%QueueField))
#ADD(%QueueField,%ValueConstruct)
#SET(%QueueFieldAssignment,%Field)
#SET(%QueueFieldComment,'Force all fields')
#ENDIF
#ENDFOR Comments
Thanks Artur!
Hi Artur,
Actually, that template was specifically for a browse. Notice the ,REQ(BrowseBox(ABC)) on the extension line.
I have another template that does the same thing for reports and processes that has ,REQ(Report(ABC)) on the extension definition.
Thanks,
Rick
In the Dct, select a SQL Table, right mouse click,(Table) Properties, there is an check box called "Enable Column Binding". The online help says"Optionally specify that all variables in the RECORD structure are available for use in dynamic expressions at runtime. The compiler will allocate memory to hold the full Prefix:Name for each variable, instead of using its own internal reference for each variable. Therefore the BINDABLE attribute increases the amount of memory necessary for the application."
The above suggests to me that all fields in the table will be not only bindable but would also in theory be included in the project() in order for the fields to be bound.
Hi Richard,
Hope all is well.
Adding BINDABLE does not automatically project all the fields for the table in a view. I did re-test to confirm.
Rick
I guess my point is when would someone want to Bind all the fields in a table using this setting and not want to Project all the fields at the same time? I cant think of a reason because one needs to project the field first before it can be bound and used in evaluation statements so it seems like a half baked feature having this DCT option.
Its a bit like Critical Sections (CS) and global threaded var's. A CS makes a global var or queue thread safe provided the programmer is observant by searching through the entire app (which can be time consuming and lots of work) and wrapping all global threaded vars in a CS. I cant see any reason NOT to use a critical section so why doesnt the RTL wrap the global vars & queues in a Critical Section automatically? Put another way, why shouldnt the RTL wrap global vars & queues in a CS automatically?
For Process or Report Procedure template this will not work. There should be a small modification :
change
#ATSTARTto
#AT(%LocalDataClassData),FIRST