Hi,
We are currently working on generating Temp-table include files from the database. Based on this article: http://knowledgebase.progress.com/articles/Article/000027330 , the fields should be sorted by the fields position (_field-rpos). Most of the generated temp-tables work fine but a few temp-tables not.
We are using AppServer and the client side does not connect to any database (only to AppServer). In the AppServer, there is a procedure program (.p) and defines a temp-table using LIKE statement to a certain database table. In the Client side, we define a temp-table using LIKE statement to a temp-table, which is defined in a include file and should be the same with the server side.
For some tables, "The caller's temp-table parameter <table-name> does not match to the target temp-table <table-name>. (5363)" error will occur when we try put the temp-table as input or output parameter of a procedure. We are not sure why the error occur, since the generated Temp-Table is based on the database table.
Does someone have any idea about this issue? We tried in several OE version: 10.2B, 11.6 and the same error occured for some table.
Thank you
Christofer
You could(/should) use the same include file to define the temp-table on the appserver and client.
And, the use of LIKE creates database coupling where none needs to exist.
To avoid problems like this, it is usually better to use one method of definition. You use both "LIKE database.table" and a static definition in an include file. My suggestion is to use the same include file for both appserver and client side. This way, the order does not matter anymore.
Thank you for the answers.
In our previous program, we use both "LIKE database.table" but since we are creating a new GUI, we eliminate the use of database on the client side but still using the same business logic on the server side. It would be troublesome for us if we convert the program on the server side to use the include file, because there would be so many programs to recompile and it would be a problem for our clients, because the previous program still using the "LIKE database.table".
It would be better if we could just maintain the program on the server side.
We just make a small program to test, from 307 database tables, there are 23 tables which have the same problem. I am still looking for hints what is the cause of this problem.
@DrMercerHush... I have done several test on my side, and have found that the LIKE option DO NOT "binds" my program to a certain database connection at runtime. The requirement of db connection is at compile time... only. Had several programs with LIKE database field, and when deployed to remote db-connectionless clients won't have any problem... I'm wondering... what am I doing wrong?