You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Same here as in #955. Should be working with tomorrow's nightly build. Can you download that tomorrow (or any later day) and check if it's improving things for you? 😃
Unfortunately it has made things worse. Now I get a rollback without an error. See the attached.
I think there is still an implied transaction. My sql file has a BEGIN TRANSACTION and COMMIT in it, so a rollback on error is to be expected. However when I remove the transaction I still get the rollback error which should not happen. If I run the previous build it seems to load the sql just fine (I fixed the errors). But in general this and #955 still exist.
Hm, sorry about that! I have just made a change which should work around this 'not an error' error. Do you still have the original SQL file causing this error somewhere? And if so can you check again with tomorrow's nightly build? If it still doesn't work it'd be interesting to know what's going on around statement number 30, probably at the end of the file.
If you think the import should print to the SQL log feel free to open a new issue for that. The problem here is that unfortunately it's not so easy to do that. When you're importing, say, 100k rows, printing them all to the SQL log would cost way too much performance. But maybe we can discuss a solution for this in a new issue 😃
In addition when I remove the BEGIN/COMMIT Transaction statements in the sql, the load is still rolled back. This should not happen. The Load process should follow what is in the sql.
Activity
Improve error handling in execution of SQL commands
MKleusberg commentedon Jan 31, 2017
Same here as in #955. Should be working with tomorrow's nightly build. Can you download that tomorrow (or any later day) and check if it's improving things for you? 😃
Improve error handling in execution of SQL commands
mtissington commentedon Feb 1, 2017
Unfortunately it has made things worse. Now I get a rollback without an error. See the attached.
I think there is still an implied transaction. My sql file has a BEGIN TRANSACTION and COMMIT in it, so a rollback on error is to be expected. However when I remove the transaction I still get the rollback error which should not happen. If I run the previous build it seems to load the sql just fine (I fixed the errors). But in general this and #955 still exist.
MKleusberg commentedon Feb 1, 2017
Hm, sorry about that! I have just made a change which should work around this 'not an error' error. Do you still have the original SQL file causing this error somewhere? And if so can you check again with tomorrow's nightly build? If it still doesn't work it'd be interesting to know what's going on around statement number 30, probably at the end of the file.
mtissington commentedon Feb 1, 2017
MKleusberg commentedon Feb 1, 2017
Thanks for testing! 😃
If you think the import should print to the SQL log feel free to open a new issue for that. The problem here is that unfortunately it's not so easy to do that. When you're importing, say, 100k rows, printing them all to the SQL log would cost way too much performance. But maybe we can discuss a solution for this in a new issue 😃
mtissington commentedon Feb 2, 2017
This error still exists and is not fixed (sorry to say)
Please see the attached, the error should be that a CHECK constraint has failed.
Test.sql.txt
In addition when I remove the BEGIN/COMMIT Transaction statements in the sql, the load is still rolled back. This should not happen. The Load process should follow what is in the sql.