RE: Days(360)...and problems with upgrade form 7.31 to 9.20

--------- From: Obnoxio The Clown[SMTP:obnoxio@hotmail.com] Sent: ceturtdiena, 2000. gada 6. j'lijs 19:10 To: andris.shirons@dati.lv; informix-list@iiug.org; obnoxio@hotmail.com Subject: RE: Days(360) From: Andris <andris.shirons@dati.lv> > >I'm not sure...aren't those DataBlades usable only for Universal Server or >IDS >2000? Yes. >We here have 7.31 Sorry, I should have guessed. Why not upgrade? Good question. Here's letter: We must do some steps before can start using new server. Our developers created a list of technical questions: 1. Database ( schema and data ) migration into new platform. 2. Application testing ( probably redeveloping will be needed ) in new environment. 3. Performance benchmarking to estimate improvement/worsening. We stoped at first step unfortunately. We tried to do this step by using standart migration tools - dbexport/dbimport. dbimport utility was stoped with error: '460 - Statement length exceeds maximum.' After changing place of procedure body inside the 'dbname.sql' file 'dbimport' completed job without any errors, but views and triggers was not created in database. We have about 400 views and 700 triggers in our system and it is very hard work to create all of them manually. We tried to create some of them. For example this statement: CREATE VIEW ... AS SELECT ... proc_name( table_name.fieldname ) ... gets error: '-674 Routine (proc_name) can not be resolved.' Procedure exists in database really. Problem is difference between types of data: table_name.field_name has NVARCHAR type but procedure's parameter - VARCHAR. There is a solution in this case: to create two instances of the procedure one with NVARCHAR parameter and the second - with VARCHAR. But to do this a lot of redeveloping needed. We tried to do this step by using 'upgrade' procedure too. With no success too. Server wrote pretty message in 'online.log': 'The database <dbname> has been converted successfully.' but our application doesn't works with new database. For example this statement: SELECT ... proc_name( table_name.fieldname ) ... gets error: '-674 Routine (proc_name) can not be resolved.' With the same reason as above mentioned. Some procedures after this converting gives error: '-684 Function (proc_name) returns too many values. This functions are procedures really, and doesn't returns any values at all. How exactly we must migrate database from 7.31 to 9.20? Wich is correct way? ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Try my dbexport/dbimport replacement utility, myexport. It uses my dbschema replacement utility, myschema, and Jonathan Leffler's sqlcmd to compatibly emulate dbexport and dbimport. The files myexport generates, as well as the schema, are compatible with dbimport and likewise myimport can use the output from dbexport. Since it uses myschema which does not suffer from some of the limitations of dbschema you MAY solve the problem that way. (HOWEVER, note that when IDS saves triggers it adds levels of parenthesis and may produce trigger code that will not reload without manual cleanup. This is not a dbschema/myschema bug but an engine bug. All three packages are available from the IIUG Software Repository. Art S. Kagel Andris wrote: > > --------- > From: Obnoxio The Clown[SMTP:obnoxio@hotmail.com] > Sent: ceturtdiena, 2000. gada 6. jûlijs 19:10 > To: andris.shirons@dati.lv; informix-list@iiug.org; obnoxio@hotmail.com > Subject: RE: Days(360) > > From: Andris <andris.shirons@dati.lv> > > > >I'm not sure...aren't those DataBlades usable only for Universal Server or > >IDS > >2000? > > Yes. > > >We here have 7.31 > > Sorry, I should have guessed. Why not upgrade? > > Good question. Here's letter: > > We must do some steps before can start using new server. Our developers > created a list of technical questions: > > 1. Database ( schema and data ) migration into new platform. > > 2. Application testing ( probably redeveloping will be needed ) in new > environment. > > 3. Performance benchmarking to estimate improvement/worsening. > > We stoped at first step unfortunately. We tried to do this step by using > standart migration tools - > > dbexport/dbimport. > > dbimport utility was stoped with error: > > '460 - Statement length exceeds maximum.' > > After changing place of procedure body inside the 'dbname.sql' file > 'dbimport' completed job without any errors, but views and triggers was not > created in database. > > We have about 400 views and 700 triggers in our system and it is very hard > work to create all of them manually. > > We tried to create some of them. For example this statement: > > CREATE VIEW ... AS > > SELECT ... proc_name( table_name.fieldname ) ... > > gets error: > > '-674 Routine (proc_name) can not be resolved.' > > Procedure exists in database really. Problem is difference between types of > data: table_name.field_name has NVARCHAR type but procedure's parameter - > VARCHAR. There is a solution in this case: > > to create two instances of the procedure one with NVARCHAR parameter > > and the second - with VARCHAR. But to do this a lot of redeveloping needed. > > We tried to do this step by using 'upgrade' procedure too. With no success > too. > > Server wrote pretty message in 'online.log': > > 'The database <dbname> has been converted successfully.' but our application > doesn't works with new database. For example this statement: > > SELECT ... proc_name( table_name.fieldname ) ... > > gets error: > > '-674 Routine (proc_name) can not be resolved.' > > With the same reason as above mentioned. > > Some procedures after this converting gives error: > > '-684 Function (proc_name) returns too many values. > > This functions are procedures really, and doesn't returns any values at all. > > How exactly we must migrate database from 7.31 to 9.20? > > Wich is correct way? > > ________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com