Hi Steffen,
I tried the following:
--------------------------
File: fill_table.sql
--------------------------
DATAUPDATE TABLE MyTable
MyFirstPrimaryKey 1
MySecondPrimaryKey 2
SET MyLongTextField 3
INFILE '\path\to\my\file\MyFile.data' COMPRESSED
LONGFILE MyLongTextField BINARY
--------------------------
File: MyFile.data
--------------------------
"3337814600","1","\path\to\my\file\MyPath\MyFileWithLotOfData.data"
The following error arises:
DATAUPDATE TABLE MyTable
MyFirstPrimaryKey 1
MySecondPrimaryKey 2
SET MyLongTextField 3
INFILE '\path\to\my\file\MyFile.data' COMPRESSED
LONGFILE TEXTE BINARY
// *
// M Error at line 1 in infile.
// E -25010: SQL error 100 = Row not found (error position: 1)
// M Last transaction committed at input line 0
// *
// M Sum of updated lines 0, Sum of invalid lines 0
...
If I set off the following SQL-Statement, I get a result - the dataset
exists thus
SELECT * FROM MyTable WHERE MyFirstPrimaryKey='3337814600' AND
MySecondPrimaryKey='1'
Regards, Christian
--
Christian Herrmann
Medical Software Systems GmbH
Neue Industriestrasse 6
66424 Homburg
+49 (6841) 755880
----- Original Nachricht ----
Von: Schildberg, Steffen [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 10. Februar 2004 10:06
An: [EMAIL PROTECTED]
Betreff: RE: Problems with DATAUPDATE
Hi Christian,
Christian Herrmann [mailto:[EMAIL PROTECTED] wrote:
[snipped working DATAUPDATE example]
>
> In another table I've got a compound primary key and that
> triad build up the
>
> SQL-statement as follows:
>
> -----------------------
> File: fill_table.sql
> -----------------------
>
> DATAUPDATE TABLE MyTable
> KEY MyPrimaryKey 1
> KEY MyPrimaryKey 2
> SET MyLongTextField 3
> INFILE 'MyFile.data' COMPRESSED
> LONGFILE MyLongTextField BINARY
>
> The File with the references looks as follows:
>
> -----------------------
> File: MyFile.data
> -----------------------
> "1","3","\MyPath\MyFileWithLotOfData_1.data"
> "2","7","\MyPath\MyFileWithLotOfData_2.data"
>
> This unfortunately doesn't work. I always get an error message:
> "Invalid end of SQL-Statement"
>
Well, yes. There is a bug in the Loader where it builds the update
statement wrong when using more than one key column in the statement.
We'll correct this with the next release.
To workaround this you can
simply leave out the KEY keywords (as this syntax is ancient anyway; yes
I know it is still in the docs and should work).
Your statement then would look like this
DATAUPDATE TABLE MyTable
MyPrimaryKey 1
MyPrimaryKey 2
SET MyLongTextField 3
INFILE 'MyFile.data' COMPRESSED
LONGFILE MyLongTextField BINARY
And it works.
The difference is the internally by the Loader built sql statement.
Omitting the KEY keywords the statement is built with a where clause. Having
only key columns as identifier the Loader builds a statement similar to this
'update <table name> set <col name> = ?, key <col name> = ?, <col name> = ?
...'
And here comes the bug on scene: the Loader adds a where keyword without any
column information in case of a compound key which confuses the kernel and
the user :-(
Regards,
Steffen
--
Steffen Schildberg
SAP DB Team
SAP Labs Berlin
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
