I had a similar problem when trying to use SQL::Translator to parse SQL intended for PostgreSQL. As the previous poster said, the problem is definitely in the input SQL you're feeding sqlt. Unfortunately, the error messages generated by the parser is fairly unhelpful.

While posting all the SQL might help, I bet the problem is in the table name. My problem was the same - it's the period. I dunno what DB2 calls it, but Postgres calls it a schema - I had fully qualified table names like financial.tbl_employees, meaning the table tbl_employees in the schema financial. Some RDMS call them namespaces, and some use more periods - Sybase uses namespace.owner.tablename, for example.

The big problem here is that SQL::Translator just doesn't have any concept of a schema/namespace. So when it parses the input SQL, it first chokes on the period, then chokes on the fact that it really doesn't have namespaces in the model. It doesn't have namespaces in the model, because RDMSs do them very differently, if at all - MySQL, your target, doesn't support them at all.

If you're feeling crazy, and like dealing with parsers, you could edit SQL::Translator::Parser::DB2 and change its parser configuration to allow periods in table names. Then you could munge the old table names and replace the periods with underscores or something, and then have SQL::Translator::Producer::MySQL barf out the data definition SQL for you. But changing the parser config is not for the faint-hearted - I am no Parse::RecDescent expert, but maybe you are.

Or, pre-process your input SQL file and replace the periods in table names with underscores. That might be simpler, in fact.

Or, if you have a running DB2 installation, you could create the old database, then slurp it out using SQL::Translator::Parser::DBI::DB2, which uses a live DBI connection as its source, rather than a SQl file. You may encounter the same difficulty, though.

Best of luck!