Hi Johan, Johan Hallgren [mailto:[EMAIL PROTECTED] wrote: > > I am trying to export data using the loadercli from an ASCII database > instance running on a 7.4.3 BUILD 027-121-048-452 database kernel, to > another ASCII database instance running on a 7.6.00 BUILD > 034-121-134-685 database kernel. I am using the loadercli that came > installed with the 7.6 database, and am specifically trying to do the > following: > [snipped successful export cmds]
> > 2. Import the same catalog and data into the 7.6 database, > using a user with the same user name as the one in the 7.4 database: > > AUTOCOMMIT ON > // > SQLMODE INTERNAL > // > SET DATE USA > // > SET MAXERRORCOUNT 1 > // > IMPORT USER CATALOG INSTREAM 'usercatalog.txt' > // > IMPORT USER DATA INSTREAM 'userdata.txt' > > This works fine until the last command, which errors out with: > > Error during execution > -->-25342 > Error restoring table TABLENAME; table exists but source table schema > and target table schema are different > > At this point, thinking that issue may be that maybe there's a foreign > key being applied that makes the import fail due to the > tables not being > imported in the correct order, I used the exported schema > definition to > manually create the new schema minus the foreign keys, and then just > execute the import data statement. However, this yields the > same error. > Also, the table on which the first error occurs has no foreign keys > defined. > I'm pretty sure this is a problem of the database parameter COLUMNCOMPRESSION which might be set to YES for your 7.6 database but does not exist on your 7.4 database. This parameter defines the length type of non primary key columns - whether they are variable long or fixed long. To verify this please have a look into the log file of the Loader. There should be a more detailed message logged. Additionally check the catalog file 'usercatalog.txt' for create table statements. Those statements should have the appendix NO FIXED LENGTH. If they do not have the appendix you can do the following to overcome the problem: - drop the user in your target database and recreate it - set the database parameter COLUMNCOMPRESSION (this is a support parameter) to NO forcing all newly created tables to have numeric columns and char-columns with length less than 31 bytes fixed length; thus the newly created tables will have the same internal representation as the tables in your 7.4 database have - run the import again If this fails again I would be interested in the Loader log file and the catalog file. Best regards, Steffen -- Steffen Schildberg MaxDB Team SAP Labs Berlin Sitz der Gesellschaft/Registered Office: Walldorf, Germany Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO), Shai Agassi, Léo Apotheker, Werner Brandt, Claus Heinrich, Gerhard Oswald, Peter Zencke Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory Board: Hasso Plattner Registergericht/Commercial Register Mannheim No HRB 350269 This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
