Re: Migration NewEra 2.x to NewEra3.0

In article <5r75fl$hm2@cssun.mathcs.emory.edu>, David Bonnici <dbonnici@ptl.com.mt> writes >Thanks to everyone who helped me solve this migration headache ! >If it interests you, my problem was getting an error message when >connecting to the database at execution time. Picture this... > >In my prebody I had this code: > >Database DATA > >VARIABLE g_atyp.* LIKE atyp.* > >Those 2 lines declare a global variable being like a database table. The >problem arose when at run-time, the "Database DATA" was executed, thus >connecting to the database, and then, the MAIN was executed (!) This Correct, if you have DATABASE database1 at the start of a module it is a compliation directive telling the 4GL compiler where to connect to so it can get information for ^^^^^^^^ variables declared LIKE database columns. EXCEPT in the case of a module containing a MAIN-END MAIN block. Here it ALSO tells the compile that before main is executed the program should connect to that database. Solution:- Have a main module which consists of MAIN CALL FN_main() END MAIN have a second 'main' type module which contains DATBASE xxx FUNCTION FN_main() DEFINE VARIABLE g_atyp.* LIKE atyp.* ... ... EBD FUNCTION >sounds strange as I thought the MAIN block was always executed first. >Therefore, with the connection existing, and trying to connect again in >the MAIN, produced errors. > >The -1801 error resulted. Briefly, to solve this error one must use the >"WITH CONCURRENT TRANSACTION" statement when connecting to the database. >(I have a Standard Engine 5 here) > The solution above will work and stop unneccessary database connections being used. Also you ould try DATABASE xxx MAIN DEFINE VARIABLE g_atyp.* LIKE atyp.* CLOSE DATABASE DATABASE yyy .... .... END MAIN > >Ok, here are the questions: > >What is the "WITH CONCURRENT TRANSACTION" statement ? Cant seem to find >it in any manual or help files. > >I have many variable declared LIKE tables. To do this, you must include >the DATABASE statement before any declarations of this type, otherwise >I'll get a compilation error (Table atyp not defined in database). Is >there a way to solve this ? > > >David -- David Williams