Randy, we don't have specific trace functionality for the DB Writer, but you may be lucky if you check Errors.txt.

Would it be possible to add in the future?

Do you have any suggestion for how to get around these errors?

Do they happen because the tables have the fields "VALUES" and/or "DESC"?

Does this mean IMan cannot update the database tables which contain reserved words?  When I write queries which use reserved words, surrounding them with brackets like [VALUES] or [DESC] will cause SQL Server to see these as field names and not keywords.  If that's the issue is it possible for that enhancement to be made?

Also, unfortunately Errors.txt does have have any information on the failed query.

I modified the destination column from "VALUES" to "VALUES_", and the sync worked.

This seems to indicate that IMan has a problem with pushing data into a table where a column name is the same as a reserved keyword in SQL.

Luckily, in our case the above solution worked for us, but I'm sure you have many customers where this may not be possible and this issue will limit their ability to move data around.

Please let me know if you would like any additional testing as this seems like a pretty decent bug.  At least APVEN, ARCUS, ARGRO, ICREOR have a "VALUES" column and at least ICCATG, ICITEM, ICPRIC, OECRDD, OECRDH, OEINVH, and OEINVD have a "DESC" column.

Randy, thanks for the update.

We're aware of some issues around reserved words, but it's reasonably difficult to resolve since each database has it's own subset (some are obviously common such as values), and not all databases follow the ANSI standard.

We will endeavour to update our documentation to include a section for dealing with reserved words.

Couldn't you simply parse the connection string for what kind of system it is?  I'm sure a large percentage of connection strings can successfully be parsed for the type of system being connected to.

Closed due to inactivity.