Subject | Re: [firebird-support] Re: Inserting 100's of thousands from a SP |
---|---|
Author | Jason Dodson |
Post date | 2005-07-12T13:41:02Z |
Lets take a server side HTML scripting language like ColdFusion or ASP.
All you CAN do is execute a query. One at a time, no less. SURE, I COULD
have two queries, one with my "Select that Inserts", then one that just
says "Commit", but I honestly can not tell you if they would even be in
the same transaction.
You understand what I mean about dangling inserts. In the context of web
users, I would have to wait for the inserts to be swept until other
users could use them.
You are telling me that I have to/should use transactions the way that
YOU see fit. My first and foremost priority is to get the data written
to the table. If I find I dont want it there, I will delete it. It isn't
the wrong thing to do in my case. Microsoft was pusing the same crap
down our throat when they insistantly enabled smartdrv whenever it could
back in the old days of DOS/Win16. But the fact of the matter is,
buffered writes werent ALWAYS the best solution.
Jason
All you CAN do is execute a query. One at a time, no less. SURE, I COULD
have two queries, one with my "Select that Inserts", then one that just
says "Commit", but I honestly can not tell you if they would even be in
the same transaction.
You understand what I mean about dangling inserts. In the context of web
users, I would have to wait for the inserts to be swept until other
users could use them.
You are telling me that I have to/should use transactions the way that
YOU see fit. My first and foremost priority is to get the data written
to the table. If I find I dont want it there, I will delete it. It isn't
the wrong thing to do in my case. Microsoft was pusing the same crap
down our throat when they insistantly enabled smartdrv whenever it could
back in the old days of DOS/Win16. But the fact of the matter is,
buffered writes werent ALWAYS the best solution.
Jason
> This option in the driver is not doing anything you could
> not have done explicitly yourself. The commit is still
> occuring outside the stored procedure, transaction control
> still rests with the client.
>
> I am not sure what you mean about the "inserts just dangle",
> it seems likely that you are referring to the fact that the
> client representation of the transaction is not aware that
> your select statement is making changes to the database (it
> is assuming that a select is non-modifying). This is quite
> different to the problem of commits in SPs - indeed the fact
> that you think commits in SPs could solve this particular
> problem shows just how dangerous it could be.
>