Re: dbimport failed - IDS 9.30 UC3

We have also experienced this exact problem with dbimport. We opened a tech support case with IBM. So far the issue is still in progress. In a nutshell, IBM says there is a known bug with dbexport/dbimport. Dbimport will sometimes fail when it attempts to use the product of dbexport. Our engineer said the problem may have been fixed in 9.4. Personally, I find it absolutely unacceptable that a fundamental, mature, required utility, such as dbimport/dbexport, should fail. The tech suggests that we might migrate to 9.4 (how do we migrate if dbimport/dbexport fails?), or that we do not use dbimport/dbexport-- they suggest onunload/onload or some other alternative, instead. (Of course, onunload/onload can't be used to migrate between versions, so that is a non-solution, also). I got the impression that IBM may not be willing to fix dbexport/dbimport, but I don't know this for sure, as we are still working through this tech support case. Anyway, some additional specifics on the "known bug", as sent to us by IBM tech support, are posted below. I have not yet had the time to examine thoroughly the .sql file produced by dbexport (and used by dbimport) to see if the "tab problem" (described below in the material from IBM) is the culprit, in our case. A cursory look seemed to indicate it is not. But, maybe that is what is the problem in your case, in which some editing may fix it. One other thing-- due to the way error messages are buffered, the problem may not be where the error message occurs. I repeat my total surprise and disatisfaction to learn that such fundamental utilities as dbimport/dbexport are broken, have been known to be broken for years, and remain unfixed. I intend no disrespect to the tech support engineer, who has been courteous and attentive. The problem is much deeper. Bug: 157723 A DBIMPORT OF A DB ENDS WITH MSG *** PREPARE SQLOBJ, 201 - A SYNTAX ERROR HAS OCCURED - WHEN ONE STORED PROCEDURE FOLLOWS ANOTHER IN SQL FILE Description: When an imported stored procedure contains if ... end if; i.e.: CREATE DBA procedure "informix".test1( ) define _anyone SmallInt; if (SELECT Count(*) FROM Anything) = 0 then let _anyone = 0; end if; end procedure; CREATE DBA procedure "informix".test2( ) define _anyone SmallInt; if (SELECT Count(*) FROM Anything) = 0 then let _anyone = 0; end if; end procedure; - it's caused by the tabs for the "end procedure" statement. Remove the tabs and it's okay. Reproduces on 9.21 and 9.30. Seems okay on 7.31 family. WORKAROUND: Remove the tab space from the "end procedure" statements in the sql file so that the statement is fully left-justified Appears that this will not reproduce in 9.4. "Hari Gupta" <hariog@yahoo.com> wrote in message news:1a1cd35b.0310052339.69ca95e2@posting.google.com... > Hi, > > I have recently installed IDS 9.30 UC3 on Linux 7.3. Done a dbexport > with -ss and started dbimport with -d <dbspace-name>. After about 5 > hrs, dbimport failed with following error: > > ------------------------------------ > *** prepare sqlobj > 201 - A syntax error has occurred. > ------------------------------------ > > The statement just above where dbimport failed was a "create trigger" > as below: > > ------------------------------------------------------------------- > create trigger "auth".trg_altask_del delete on "auth".aualtask > referencing old as old > for each row > ( > execute procedure "auth".sp_stop_clock('D' , , ,old.doc_typ > ,old.doc_yer ,old.doc_num ,old.doc_prt ,old.wrk_typ ,old.seq_num > , , , ,old.mdu_ref )); > > *** prepare sqlobj > 201 - A syntax error has occurred. > ------------------------------------------------------------------- > > Pl. note that after this create statement, all statement were update > stats. > So what I did, created trigger seperately and ran update stats based > upon dbexport SQL file using dbaccess. > > I did read few archives about this error but none of them reported > above error followed by 201 error. > > There was an issues similar to this with dbimport in earlier verson of > IDS but I don't think it will be still an known bug with IDS 9.30 UC3. > > Can some guru help me about this please ? > > Pl. let me know if onconfig or some other info. is needed. > > TIA > > Hari

"David E. Grove" <david_grove@correct.state.ak.us> wrote in message news:vo3rrqfnf163fe@corp.supernews.com... > We have also experienced this exact problem with dbimport. > The tech suggests > that we might migrate to 9.4 (how do we migrate if dbimport/dbexport > fails?), or that we do not use dbimport/dbexport-- they suggest > onunload/onload or some other alternative, instead. (Of course, > onunload/onload can't be used to migrate between versions, so that is a > non-solution, also). Depending upon IDS release, onload ususally has bugs or "features" that make using it somewhere between "difficult and time-consuming" and "impossible". > I got the impression that IBM may not be willing to fix dbexport/dbimport ... The attitude seems to be that, if you have a reasonable workaround (which, correct me if I'm wrong, they have provided) they'll probably not fix it in current releases. > I repeat my total surprise and disatisfaction to learn that such fundamental > utilities as dbimport/dbexport are broken, have been known to be broken for > years, and remain unfixed. I echo that. Well, maybe not the surprise, but certainly the dissatisfaction ... :-)

> The attitude seems to be that, if you have a reasonable workaround (which, > correct me if I'm wrong, they have provided) they'll probably not fix it in > current releases. We have not yet established that there is a workaround. The last few days I've been diverted to other more urgent activities, so I haven't determined for sure that the suggested work around applies. I need to examine more closely the .sql file produced by dbexport. We have 1000 tables and similar number of SPs. An initial, brief examination of the .sql file in the vicinity of the error message doesn't appear to display any left justification issues. So, no workaround, yet. DG "Neil Truby" <neil.truby@ardenta.com> wrote in message news:blt5l7$g78sr$1@ID-162943.news.uni-berlin.de... > "David E. Grove" <david_grove@correct.state.ak.us> wrote in message > news:vo3rrqfnf163fe@corp.supernews.com... > > We have also experienced this exact problem with dbimport. > > > The tech suggests > > that we might migrate to 9.4 (how do we migrate if dbimport/dbexport > > fails?), or that we do not use dbimport/dbexport-- they suggest > > onunload/onload or some other alternative, instead. (Of course, > > onunload/onload can't be used to migrate between versions, so that is a > > non-solution, also). > > Depending upon IDS release, onload ususally has bugs or "features" that make > using it somewhere between "difficult and time-consuming" and "impossible". > > > I got the impression that IBM may not be willing to fix dbexport/dbimport > ... > > The attitude seems to be that, if you have a reasonable workaround (which, > correct me if I'm wrong, they have provided) they'll probably not fix it in > current releases. > > > I repeat my total surprise and disatisfaction to learn that such > fundamental > > utilities as dbimport/dbexport are broken, have been known to be broken > for > > years, and remain unfixed. > > I echo that. Well, maybe not the surprise, but certainly the > dissatisfaction ... :-) > >