Share
ReportI am curious if anyone has developed an SL screen (using the SDK toolkit) using multiple SAFGrid controls with each control referring to the same physical SQL table.
A little explanation of why I need to do this. I need to develop a screen that presents different views of data from the same SQL table. For example, one grid presents an open credits, the second grid presents and charges that have some sort of credit or payment applied to them and the third grid presents any changes that have an open balance. These presentations include some additional fields that do not exist in ARDoc so the screen utilizes a working table that is populated base on some user-specified criteria in the header of the form and this table also includes these new fields needed for the process behind the screen.
I have attempted to pull this off by creating 3 alias definitions in the DH file definition for the table and then referring to those alias names in the SETADDR calls and in the field property of each SAF control in each grid cell. I have 3 different DBNAVs defined to set the selection criteria for each SAFGrid. The DBNAVs refer to the actual SQL table name and not the alias names. The DETAILSETUP calls refer to the cursors established in the SETADDR and SQLCURSOREX calls.
However, when I attempt to open the screen it tells me that it cannot locate the field xxxxxx in table yyyyyy for the control form1.zzzzzz. where xxxxxx is the actual field name in the SQL table and what is in the field property of the control and yyyyyy is the alias name for the table and zzzzzz is the control name linked to that field.
If I trap the code after the SETADDR calls and before the SCREENINIT call I can refer to the field in the immediate window and see its value so I know the SETADDR and DH files are in sync. I can even execute the SCREENINIT call and still am fine. I can then successfully make the DETAILSETUP calls for all 3 SAFGrids. However, when I make the first DETAILLOAD call I get the error message. The DETAILLOAD calls are referring to the cursors set up for the alias table names. If I do not make the DETAILLOAD calls at the form load time (e.g., let SL control the loading of the grid controls) I get the same error.
I cannot tell if my issue is because I am using alias names for the one table or the fact that I have multiple grids referring to the same table or what. If I take the offending field and change its property to refer the actual table name (which also has a SETADDR and such set up for it) then the field in error changes to the next control in the grid. If I change all the SAFGrid controls to refer to the actual table name then the form no longer gives the error but the SAFGrids do not populate correctly. What is interesting is that the SAFGrids get the expected number of rows but each field is either blank or a 0 depending on the control type.
I cannot have all 3 SAFGrids referring to the same actual SQL table name because each grid has to be at its own level and the SETADDR calls will then complains that the level has already be used in another SETADDR call.
I realize that this is a complex posting and the explanation is lengthy but more detail is typically better than less. I have built several other screens with more than one SAFGrid control on it but those have always had each grid matched up to a single SQL table. This is the first time I have attempted to present different views (not actual SQL views, just different DBNAVs for each grid) in separate grids. I may be pushing SWIN beyond its limits here but I am surprised how powerful SWIM can be if you only know how to play by its rules.
*This post is locked for comments
All responses (
Answers (
4,710
