| 1 |
On 04/08/2014 15:31, Martin Vaeth wrote: |
| 2 |
> J. Roeleveld <joost@××××××××.org> wrote: |
| 3 |
>>> |
| 4 |
>>> So you have a command which might break due to hardware error |
| 5 |
>>> and cannot be rerun. I cannot see how any general-purpose scheduler |
| 6 |
>>> might help you here: You either need to be able to split your command |
| 7 |
>>> into several (sequential) commands or you need something adapted |
| 8 |
>>> for your particular command. |
| 9 |
>> |
| 10 |
>> A general-purpose scheduler can work, as they do exist. |
| 11 |
> |
| 12 |
> I doubt that they can solve your problem. |
| 13 |
> Let me repeat: You have a single program which accesses the database |
| 14 |
> in a complex way and somewhere in the course of accessing it, the |
| 15 |
> machine (or program) crashes. |
| 16 |
> No general-purpose program can recover from this: You need |
| 17 |
> particular knowledge of the database and the program if you even |
| 18 |
> want to have a *chance* to recover from such a situation. |
| 19 |
> A program with such a particular knowledge can hardly be called |
| 20 |
> "general-purpose". |
| 21 |
|
| 22 |
|
| 23 |
Joost, |
| 24 |
|
| 25 |
Either make the ETL tool pick up where it stopped and continue as it is |
| 26 |
the only that knows what it was doing and how far it got. Or, wrap the |
| 27 |
entire script in a single transaction. |
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
Alan McKinnon |
| 32 |
alan.mckinnon@×××××.com |
Archives