 | |
Import data from file
sybase.public.sqlanywhere.general sybase.public.sqlanywhere.general
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: Import data from file -
01-26-2010
, 01:59 PM
|
Good points, John - thanks for this clarification. LOAD TABLE should still be an atomar operation, for sure. I guess it might still be considered "complete" when an option says "DO AS MUCH WORK AS POSSIBLE" and LOAD TABLE does just that - i.e. load rows in the order specified and then commit. So a "unfitting row" would be more or less like a "end of row" marker. I see that this, however, won't fit to the page-level logging if the consistency checks are applied AFTER the load. Thinking more about that, my approach is primarily focussed on testing (i.e. checking failed LOAD TABLE statements), and as such, performance is much less of a concern than ease of use. For thsat reason, INPUT might fit better (as it uses a bunch of INSERTS internally AFAIK), and the "stop vs. continue" would also fit better. However, the syntax and facilities of both statements are quite different. Therefore, in case of a LOAD TABLE with failing data, it would not be of much help if one had to rewrite an according INPUT statement to test further. Just my 2 cents Volker |
#12
| |||
| |||
|
|
So you want STOP ON ERROR to do a commit as if the load had been successful but still report an error -- not just leave the data uncommitted. I think it's possible but somehow doesn't sit well with me... Those sorts of semantics would need to be explored by the query processing team. Not reporting the error would make a full load and a partial load indistinguishable. -john. |
#13
| |||
| |||
|
|
Well, would a COMMIT be obligatory? - I guess so, as that's the way LOAD TABLE is declared to work, and I think it would be very cumbersome if LOAD TABLE would have to be declared as "Does an automatic commit unless...". Then the COMMIT combined with an error message (or just a warning? - might be more fitting) seem to be the only approach I can think of. However, I share your point of view that this seems somewhat clumsy. Maybe someone has a brighter idea? Regards Volker John Smirnios [Sybase] wrote: So you want STOP ON ERROR to do a commit as if the load had been successful but still report an error -- not just leave the data uncommitted. I think it's possible but somehow doesn't sit well with me... Those sorts of semantics would need to be explored by the query processing team. Not reporting the error would make a full load and a partial load indistinguishable. -john. |
Breck Carter - Blog: http://sqlanywhere.blogspot.com/
SQLA questions and answers: http://sqla.stackexchange.com
RisingRoad helps SQL Anywhere developers make better databases
http://www.risingroad.com/
Breck.Carter at gmail
#14
| |||
| |||
|
|
Start a new thread, maybe in product futures (or, maybe, somewhere else  Breck On 27 Jan 2010 00:50:06 -0800, Volker Barth No_VBarth (AT) Spam_GLOBAL-FINANZ (DOT) de> wrote: Well, would a COMMIT be obligatory? - I guess so, as that's the way LOAD TABLE is declared to work, and I think it would be very cumbersome if LOAD TABLE would have to be declared as "Does an automatic commit unless...". Then the COMMIT combined with an error message (or just a warning? - might be more fitting) seem to be the only approach I can think of. However, I share your point of view that this seems somewhat clumsy. Maybe someone has a brighter idea? Regards Volker John Smirnios [Sybase] wrote: So you want STOP ON ERROR to do a commit as if the load had been successful but still report an error -- not just leave the data uncommitted. I think it's possible but somehow doesn't sit well with me... Those sorts of semantics would need to be explored by the query processing team. Not reporting the error would make a full load and a partial load indistinguishable. -john. -- Breck Carter - Blog: http://sqlanywhere.blogspot.com/ SQLA questions and answers: http://sqla.stackexchange.com RisingRoad helps SQL Anywhere developers make better databases http://www.risingroad.com/ Breck.Carter at gmail |
#15
| |||
| |||
|
|
Start a new thread, maybe in product futures (or, maybe, somewhere else Breck On 27 Jan 2010 00:50:06 -0800, Volker Barth No_VBarth (AT) Spam_GLOBAL-FINANZ (DOT) de> wrote: Well, would a COMMIT be obligatory? - I guess so, as that's the way LOAD TABLE is declared to work, and I think it would be very cumbersome if LOAD TABLE would have to be declared as "Does an automatic commit unless...". Then the COMMIT combined with an error message (or just a warning? - might be more fitting) seem to be the only approach I can think of. However, I share your point of view that this seems somewhat clumsy. Maybe someone has a brighter idea? Regards Volker John Smirnios [Sybase] wrote: So you want STOP ON ERROR to do a commit as if the load had been successful but still report an error -- not just leave the data uncommitted. I think it's possible but somehow doesn't sit well with me... Those sorts of semantics would need to be explored by the query processing team. Not reporting the error would make a full load and a partial load indistinguishable. -john. -- Breck Carter - Blog: http://sqlanywhere.blogspot.com/ SQLA questions and answers: http://sqla.stackexchange.com RisingRoad helps SQL Anywhere developers make better databases http://www.risingroad.com/ Breck.Carter at gmail |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.