COPY FROM STDIN data errors and "See server log for details": Which Server log?

Hi Marco,

This might be helpful to you> https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/AdministratorsGuide/BulkLoadCOPY/CapturingLoadExceptionsAndRejections.htm

You can also save rejected data in table> Saving Load Rejections (REJECTED DATA) https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/AdministratorsGuide/BulkLoadCOPY/SavingLoadRejections.htm

Hope this might be helpful!

-Deepika YM

@marcothesane - I think this is a related JIRA:

Obscure error message during ODBC batch inserts - http://jira.verticacorp.com:8080/jira/browse/VER-67024

Latest update:

I agree that we have a bad error message in the case where the only problem with a batch insert is that some rows were rejected. I don't know the history behind this, but the "see server log for details" message is set as the message used when rows are rejected, and it shouldn't be; as you noted, there is no useful information in vertica.log when this happens. My first suspicion was that this message was simply being used too generically, but in fact, the only time it is used is when there are rejections. This is a bug, and I'm going to leave this JIRA open as a result. My thought is that this message should actually say, "check the parameter status array"; that is something that the application could actually do to find out which rows had problems. I don't have the cycles to deal with it at this moment, but we'll get to it when we can.

There are cases where you would see a more meaningful message, but unfortunately that's not under our control. For example if you were inserting date values in a batch insert and some rows had dates in invalid formats, Simba would catch that and issue their own error message about it, which SQLGetDiagRec() would give you in addition to our "see server log for details" message. But while Simba can detect things that violate standards, they don't catch things like whether or not a string value is going to cause right truncation due to the definition of the column. Unfortunately, getting this kind of detail back to the client for all reasons why a row might be rejected would require a non-trivial protocol change.

For the moment, the best thing we can tell users is that if they see this error message, they should ignore the advice to check the server log and instead make sure that their applications are checking the parameter status array; that's where they're going to get some indication of where the problem is.