| Subject | Re: [IBO] Transaction error mystery: suspected IB_Cursor bug |
|---|---|
| Author | Marco Menardi |
| Post date | 2002-11-07T12:50:42Z |
--- In IBObjects@y..., Helen Borrie <helebor@t...> wrote:
Are you telling me that only for DML there is a need of transaction? What about updates upon the same data if a non DML is performed by this code, but the transaction is left open?
But, re-reading it sometime for help in my program design, a lot of questions seems not to be answered.
Just some examples right from my (bad) memory:
a) often you find code like qryMy.Prepare; qryMy.Open; but as far as I know, open first prepares the query, so is it necessary?
b) here in this list, when describing cursor usage, no code is provided for closing it, so one could guess: does it automatically close?
c) transactions and DML (see my above dubts)
d) why code like this (GSG, About datasets states, Editing) (I've added line number for reference)
...
1) if prepared then unprepare:
2) ParamByName('Name2').AsString := Name2;
3) ParamByName('Name1').AsString := Name1;
4) Prepare;
5) ExecSQL
...
here:
1) Why unprepare the query? If stays prepared, lot of work is already done by the server.
4) ParamByName automatically prepares the query if not prepared, and this seems not the right sequence (does prepare clears parameters?)
5) As you told me, ExecSQL is not the proper method, since is only for VCL compatibility. Usa .Execute instead.
This is just a sample, but a lot of confusion can derive from even a not very clear or wrong example :)
btw, GSG is still at 1.2.8 release, but a lot has been asked and pointed out by a reader some weeks ago. Helen, you did a great job with GSG, but belive me, it's REALLY an important document, we learn the basic here, so you should improve it the most you (and we, reporting inprecisions) can.
I've a document with (in italian), I've reported a lot of topic that only experimenting I've understood, but I see that a lot of basic stuff is not clear to me (and, sure, for many others).
Do you mind my translate in english the most improtant (on my opinion) parts, have you to revise it and publish in some ways (ibo tech sheets)? I sent you a draft of some points time ago, but you asked me to make a better organized document. I think that it would better having a bad organized document than not a document at all. And I would like it to be an "open source" document, so the knowledge of IBO users can be added time after time. Ok, I'm not the most qulified person to do so, but if nobody starts... ;)
Let me know...
regards
Marco Menardi
> At 11:38 AM 07-11-02 +0000, you wrote:[cut]
> >--- In IBObjects@y..., Helen Borrie <helebor@t...> wrote:
>
> I just can't see why you have to start and commit a transaction each timeAs far as I know, Interbase needs a transaction even for a SELECT (everything is done by interbase inside transactions, apart generators), so I only made an explicit control to stop the transaction as soon as possible.
> you run this query, is all, since you don't appear to be doing any
> DML.
Are you telling me that only for DML there is a need of transaction? What about updates upon the same data if a non DML is performed by this code, but the transaction is left open?
> Neither do I understand why you close the cursor each time. YouWhy left this open? This is code that should run only one time. Happends that if the user changes some program configurations, must be done again or restart the app (and this is why I discovered this problem only now).
> simply need to call First to refresh it.
>Could you confirm me that my code is correct and SHOULD work? So is it a ib_cursor bug?
> >So seems that something in IB_Cursor is not cleared properly when .Cursor
> >is issued
> (btw, what about a chapter in GSG that describes exactly all theWell, you know I was one of the first buyer of your guide, and I've found it *really* usefull, I love it.
> >steps for transaction and query/storedproc/cursor usage?).
>
> That's probably easier for you to answer right now than for me (I'm
> actually working at the moment...with a big database and several
> utilities...) Describes *exactly* *all the steps* ? I guess it depends
> which you are talking about, since each (except SP) has its own
> section...just use the index.
But, re-reading it sometime for help in my program design, a lot of questions seems not to be answered.
Just some examples right from my (bad) memory:
a) often you find code like qryMy.Prepare; qryMy.Open; but as far as I know, open first prepares the query, so is it necessary?
b) here in this list, when describing cursor usage, no code is provided for closing it, so one could guess: does it automatically close?
c) transactions and DML (see my above dubts)
d) why code like this (GSG, About datasets states, Editing) (I've added line number for reference)
...
1) if prepared then unprepare:
2) ParamByName('Name2').AsString := Name2;
3) ParamByName('Name1').AsString := Name1;
4) Prepare;
5) ExecSQL
...
here:
1) Why unprepare the query? If stays prepared, lot of work is already done by the server.
4) ParamByName automatically prepares the query if not prepared, and this seems not the right sequence (does prepare clears parameters?)
5) As you told me, ExecSQL is not the proper method, since is only for VCL compatibility. Usa .Execute instead.
This is just a sample, but a lot of confusion can derive from even a not very clear or wrong example :)
> But I don't think you're going to findWell, nothing "normal" here ;))
> instructions for what you're describing. It doesn't sound like a very
> "normal" sort of task to me.
btw, GSG is still at 1.2.8 release, but a lot has been asked and pointed out by a reader some weeks ago. Helen, you did a great job with GSG, but belive me, it's REALLY an important document, we learn the basic here, so you should improve it the most you (and we, reporting inprecisions) can.
I've a document with (in italian), I've reported a lot of topic that only experimenting I've understood, but I see that a lot of basic stuff is not clear to me (and, sure, for many others).
Do you mind my translate in english the most improtant (on my opinion) parts, have you to revise it and publish in some ways (ibo tech sheets)? I sent you a draft of some points time ago, but you asked me to make a better organized document. I think that it would better having a bad organized document than not a document at all. And I would like it to be an "open source" document, so the knowledge of IBO users can be added time after time. Ok, I'm not the most qulified person to do so, but if nobody starts... ;)
Let me know...
regards
Marco Menardi