 | | | Error -25342 when importing user data from a 7.4 database usingloadercli on | Error -25342 when importing user data from a 7.4 database usingloadercli on 2007-03-28 - By Schildberg, Steffen
Back
Hi Johan,
Johan Hallgren [mailto:johan.hallgren@(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/maxdb?unsub=mysql@(protected)
|
|
|