Re: Moving Data from Informix SE 4 to Informix SE 7

Not sure what the errors with the dates and floats can be as the originator already posted that he can unload the tables OK, its just the dbexport fails. If the data itself was corrupt the unload would fail too. Michael Krzepkowski <mkrzepkowski@hotmail.com> wrote in message news:<Wl9Zc.275619$M95.17155@pd7tw1no>... > JJ wrote: > > Run a "check table tablename" on every table (or "bcheck -n" at a shell > > prompt within the .dbs directory on each table file, which is the filename > > without the ".dat" or ".idx"). That will let you know which tables are > > corrupted. > > > > Once you get a list, run "repair table tablename" on every corrupt table (or > > "bcheck -y" at a shell prompt within the .dbs directory). That will fix any > > table corruption problems - but make sure you have backups. > > > > Then dbexport should work. > I belive this will fix bad index problems, but not issues with corrupted > decimal/float/date fields that unload is trying to convert to ascii. > > I wonder if including rowid in selection for unload might help in > excluding bad records. > > HTH > > Michael > > > > > Do you have a multi-gig tape drive? You can dbexport directly to the tape > > if you don't have enough disk space or run into filesystem limit problems. > > (To go to disk, you ought to be able to create a large-file enabled > > filesystem in AIX, and use the command "ulimit 0" as a superuser to turn off > > file size limits.) > > > > Just curious - have you tried your application with SE 7? Do you use the > > 4GL that compiles to C (c4gl) or p-code (fglpc)? It's been a while, but I > > used FourGen case tools a long time ago. I thought they compiled stuff into > > the 4GL p-code runner and you had to rebuild fglgo and recompile all of your > > apps if you moved to a different version of 4GL. The old 4GL runtime might > > work with SE 7, but you need to use the Relay Module (sqlrm), which slows > > things down. > > > > > > "Smitty" <wolphie@hotmail.com> wrote in message > > news:4f39af7f.0408301540.5de8ce63@posting.google.com... > > > >>I'm a programmer/analyst at a medical services company. At the core > >>of our system is an Informix SE 4.x database - (c)1990, with all > >>business software written in-house using Informix 4GL and FourGen (a > >>CASE tool also from the early 90s). Everything runs from an RS/6000 > >>server (AIX 4.x), accessed by the users using TELNET software on their > >>Windows PCs (everything in text-mode only). Approx. 200 users > >>scattered throughout 24 offices in several states are logged in at any > >>given time. > >> > >>In January they finally decided to upgrade the old Informix database. > >>The primary reason: to get ODBC connectivity to Windows, thus allowing > >>the creation of Windows front-ends for the screens and reports. > >>Informix SE 4 is so old that it is seemingly impossible to find any > >>Windows connectivity solution to work with it. So they purchased > >>Informix SE 7.x and licenses and were ready to go. > >> > >>Unfortunatelly the company who sold us the new Informix product (and > >>is helping us with the migration to SE7) tell us that some of our > >>databases/tables are corrupted and the move is extremely difficult. > >>DBEXPORT bombs out on certain databases because of corrupted system > >>tables and/or bad data. It's going to be a lot more hours and money > >>"if" they can help us. Although we realized the system hadn't been > >>properly maintained (under the previous IT manager), we didn't foresee > >>the severity of this problem. Everything (tables and database > >>functions) seems to behave normally during daily use (postings, data > >>entry, etc.) and has for years. > >> > >>So bottom line: 14 years (a few hundred GBs) of our data are stuck in > >>Informix SE4 and moving everything to SE7 seems really difficult and > >>expensive. I'm not a DBA, mostly an Windows application programmer, > >>but in my naievity I thought I could use DBSCHEMA to create empty > >>shells of our tables in SE7, then UNLOAD each SE4 table to a delimited > >>file, then LOAD those files into SE7. This worked in theory, but I > >>ran into several difficulties: a file-size limit (2GB?) when using > >>UNLOAD, and the sheer time the process took (10-12 hours to LOAD large > >>tables). Plus the company is constantly modifying data throughout the > >>week, so after testing is complete, the final migration would have to > >>all be completed over a weekend, with everyone ready to roll in SE7 > >>first thing on a Monday morning. My UNLOAD/LOAD method seems too slow > >>to unload/copy/load everything within 48 hours. > >> > >>The company we're working with seems to know what they're doing (we're > >>still waiting word on whether they can help us and if so how much > >>extra time/expense it will involve). It's just so frustrating to be > >>so stuck on something that seems (maybe deceptively) simple. I can > >>get the data out and load it, but it's just SO SLOW! If anyone has > >>experience with such a problem, or perhaps sees something obvious I'm > >>missing, please let me know. Although we are working with a seemingly > >>competent partner, it would be negligent not to keep our eyes open to > >>every option. Thanks... Joe > > > > > >