Difference between Do and Do transacion..........

[ran]

Guys,
Please help., I am not able to find out the actual practical differece bet Do and Do transaction block while uploading data.......
Please let me know some example.......

 

[RealHeavyDude]

It all depends on the default transaction scope and whether or not you need to override that behavior or don't want to rely on it.

Every statement that changes the database will cause a transaction to occur. This is also the case when you fetch records with exclusive-lock. The transaction is then scoped to next block with transaction capabilities. This might be the procedure itself!

You can check the transaction scope when you supply the LISTING option to the COMPILE statement (see online help).

Therefore if you use DO TRANSACTION you may achieve the following:

• If the default transaction scope is lager you are causing a sub transaction and the compiler may give you a warning.
• If the default transaction scope is smaller you are explicitely exenting the transaction scope.

Again, it all depends on what it is you want to achieve, but your question leeds me to the impression that you are not familiar with transaction or record scope and you should make yourself familiar with them because otherwise they might bite you. In general I would advise to keep to the transactions as short as possible unless there is a real need to have biggers ones.

HTH, RealHeavyDude.

 

[ran]

I want some example for that to identify a difference........
I used the cimlaod for do block and do transaction but I got the same result....
I have 6 data while error occur at 5th record wat shud upload using cim in do blcok and do transaction.......
Please explain with example.

 

[RealHeavyDude]

Hello Ran,

don't get mad at me, _BUT_ understanding transaction and record scope is IMHO the most basic Progress 4GL (or ABL as it is called nowadays) programming knowledge that you need and you should make yourself familiar with it. Giving you examples for all possible scenaries is IMHO beyond the scope of this forum.

If I were you, to begin with, I would have a look into the chapters "Record buffers and Record scope" and "Managing Transactions" in the ABL Handbook coming with the documentation.

Best regards,
RealHeavyDude.

 

[TomBascom]

You might want to suggest to your employer that a training class in 4GL programming principles is needed.

 

[GregTomkins]

Here's a quick example that illustrates the difference:

DO TRANSACTION:
CREATE gncode.
ASSIGN table_name = "FOO" LAST_dt = TODAY.
END.
PAUSE.
DO TRANSACTION:
CREATE gncode.
ASSIGN table_name = "BAR" LAST_dt = TODAY.
END.

If you CTRL-C during the PAUSE, the code as written will still have created the first ('FOO') record.

If you remove the TRANSACTION keyword from the DO blocks, and do the same thing, neither record will have been created.

If you get a compiler error because you didn't change the table and field names to ones actually in YOUR database, well, then, I don't think any of us can help you.

This concept should be easy enough to sort out with a little reading and experimentation (though personally I really hate the way Progress's transaction guessing works - that's another story).

 

[TomBascom]

... personally I really hate the way Progress's transaction guessing works - that's another story.

Personally I never let Progress guess. I always tell it exactly where I want my transactions to be.

 

[RealHeavyDude]

It totally I agree with Tom. The Progress 4GL really does a good job to simplify things - and don't we love it for that?

And, just sometimes, some odd default behavior which has it's justification from good ole V6 days when our world was still perfect, bites you where it really hurts - and then you love the Progress 4GL even more

I have seen so many Progress developers over the years not understanding the basic principles on which the 4GL is built - and they wonder why their code is not behaving like the think it should. Worse yet, some of them hired me as a consultant and the first thing I heard from him was, that he was developing programs since 20+ years and nobody is going to tell him how to code. I was just wonder why he hired me in the first place - but that's another story.

Call me a control freak - but I like to take responsability for what is happening when my code is executed. Therefore I am always very strict when it comes to rely on default behavior ...

Regards,
RealHeavyDude.

 

[GregTomkins]

Well... if you want to tell your database when to start and end a transaction, you can't get much simpler and clearer than the SQL 'BEGIN TRANSACTION' or 'AUTO COMMIT' methods.

Whereas in Progress, unless you have figured out some way to hack the Progress executables, you may have to go hunting around to find out where the EXCLUSIVE-LOCK happened, think about record scope, etc. (Yes I know XREF helps with this).

This might be more practical in a single-developer or small team environment, but a bit tougher in a dozens of developers, multi-city scenario.

 

[TomBascom]

That's odd. DO TRANSACTION does the trick quite nicely for me. I also find that DO FOR does wonders for keeping record locks where you want them.

As for miscreant developers... make an example out of one or two in the parking lot and they'll start behaving (Use live video conferencing if you have a distributed team.)