Hi,
When I start my job, I get this error message :
DBD::mysql::st execute failed: Erreur de syntaxe près de '(19) NOT NULL
, `nomClient` VARCHAR (30) NOT NULL
)' Ã la ligne 6 at C:\JasperETL\workspace\.Perl\DATEVCCIRCE.job_new.pl line 330.
can't create table at C:\JasperETL\workspace\.Perl\DATEVCCIRCE.job_new.pl line 330
I verified my schemas many times and I don't think there are mistakes. I also checked up the DATEVCCIRCE.job_new.pl file at line 330, it seems there is a problem in table creation! the line 330 is this one:
$sth_tDBOutput_1->execute()
So, does someone have an idea about this problem? Where could I modify the create table query used by the perl file?
thanks
Nicolep
When I start my job, I get this error message :
DBD::mysql::st execute failed: Erreur de syntaxe près de '(19) NOT NULL
, `nomClient` VARCHAR (30) NOT NULL
)' Ã la ligne 6 at C:\JasperETL\workspace\.Perl\DATEVCCIRCE.job_new.pl line 330.
can't create table at C:\JasperETL\workspace\.Perl\DATEVCCIRCE.job_new.pl line 330
I verified my schemas many times and I don't think there are mistakes. I also checked up the DATEVCCIRCE.job_new.pl file at line 330, it seems there is a problem in table creation! the line 330 is this one:
$sth_tDBOutput_1->execute()
So, does someone have an idea about this problem? Where could I modify the create table query used by the perl file?
thanks
Nicolep
6 Answers:
Posted on March 7, 2007 at 12:18pm
Hi,
Can you explain about your job, components used, action specified in your tDBOutput, and more.
Logically, Create table action is based on Schema (going to input component).
If you need modify your own perl script code :
- Export your job (click-right and choose to export Job)
- Open the archive file and modify you .pl file.
But i think that you have a problem in the input definition of the schema before creating table.
Regards.
______
Thank you for your support!
Christophe ANTOINE
Talend R&D Engineer
Can you explain about your job, components used, action specified in your tDBOutput, and more.
Logically, Create table action is based on Schema (going to input component).
If you need modify your own perl script code :
- Export your job (click-right and choose to export Job)
- Open the archive file and modify you .pl file.
But i think that you have a problem in the input definition of the schema before creating table.
Regards.
______
Thank you for your support!
Christophe ANTOINE
Talend R&D Engineer
Posted on March 7, 2007 at 3:34pm
Thanks for your help, the problem is solved. I didn't notice that I was trying to duplicate a primary key value! That was why jasperETL couldn't create the table. So it was indeed a schema problem.
Thanks.
Nicole
(I've just posted a new message, can you read it please??!)
Thanks.
Nicole
(I've just posted a new message, can you read it please??!)
Posted on March 8, 2007 at 10:00am
Hi Christophe,
I have a similar problem:
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(7)
, `UPDATE_DATE` DATETIME (7) NOT NULL
, `UPDATE_USER` DOUBLE (9,0) NOT NULL
' at line 8 at C:\Software\Jasper\JasperETL-Win32-r1732-V1.1.1\workspace\.Perl\TEST.job_Import1.pl line 454.
My task is trying to copy a table from Oracle 9 to MySQL.
I used schema export and import to synchronize the schemas.
I think it looks like a bug. When I edited the schema and removed 'length' from two date fields, the task executed successfully, however, the dates were not copied to the target table.
Cheers,
Alex
I have a similar problem:
DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(7)
, `UPDATE_DATE` DATETIME (7) NOT NULL
, `UPDATE_USER` DOUBLE (9,0) NOT NULL
' at line 8 at C:\Software\Jasper\JasperETL-Win32-r1732-V1.1.1\workspace\.Perl\TEST.job_Import1.pl line 454.
My task is trying to copy a table from Oracle 9 to MySQL.
I used schema export and import to synchronize the schemas.
I think it looks like a bug. When I edited the schema and removed 'length' from two date fields, the task executed successfully, however, the dates were not copied to the target table.
Cheers,
Alex
Posted on March 8, 2007 at 11:47am
Hi,
I come back on my previous message where I said that I found the solution. The problem wasn't the duplicata of primary key value but it seems that the problem comes from "day" type. The creation of the table raises a problem when I've got a day type in my schema. When I replace the day type by string type, the problem doesn't appears. It may exist a problem of compatibility between jasperETL "day" type and in my case, Mysql "date" or "datetime" type.And your message, Alex, seems to confirm this hypothesis.
Have someone a solution other that changing the type to string??
Thank
Nicolep
I come back on my previous message where I said that I found the solution. The problem wasn't the duplicata of primary key value but it seems that the problem comes from "day" type. The creation of the table raises a problem when I've got a day type in my schema. When I replace the day type by string type, the problem doesn't appears. It may exist a problem of compatibility between jasperETL "day" type and in my case, Mysql "date" or "datetime" type.And your message, Alex, seems to confirm this hypothesis.
Have someone a solution other that changing the type to string??
Thank
Nicolep
Posted on March 12, 2007 at 10:21am
Hi,
I don't think that using string type instead of date is acceptable solution - at least not for me.
I managed to create a table containing date with JasperETL. In order to do that I removed the "length" value from MySQL schema.
But - the data is not copied anyway, so I think it's a JasperETL bug in handling date fields in MySQL database.
Cheers,
Alex
I don't think that using string type instead of date is acceptable solution - at least not for me.
I managed to create a table containing date with JasperETL. In order to do that I removed the "length" value from MySQL schema.
But - the data is not copied anyway, so I think it's a JasperETL bug in handling date fields in MySQL database.
Cheers,
Alex
