Hi,

At the moment I have a bunch of DLLs that contain the business logic
for my core executable.
At the moment, when an error occurs in a DLL it is simply raised back
using Err.Raise through the calling procedures until it reaches the
core exe where it is handled and displayed to the user.

Due to the way the DLLs reference each other the error could have been
passed down through 3 or more DLLs and through twice as many
procedures, and by the time the error has been propagated back to the
core exe it is impossible to do anything sensible with it.

I have pointed out this flaw and intend introduce error handling and
display at the source of the error, i.e. in the DLLs themselves.

My senario is this however.

The core exe calls a function in DLL 1.
DLL 1 starts a database transaction and then calls a function in DLL
2.
DLL 2's funtion errors for some reason, and displays the error to the
user waiting them to press OK. When the user does, DLL 2's funtion
returns to DLL 1 which then decides to either Commit or Rollback the
transaction based on the return value from DLL 2's function.

The problem is that the transaction will have been open all that time
hence locking the database tables for other users.

As we know transactions should be a short as posible and we should not
place the user in control of their length.

Does anyone have any thoughts on this?

Thanks.

If the error needs to be displayed to the user then you should immediately
rollback, display the error, correct of necessary and try again from the
start.

Do not attempt to change the code mid-transaction you will end up in an
awful mess - imagine if the user leaves it to email you for advice or the
app crashes leaving half finished transactions.

Chris.

Hi,

At the moment I have a bunch of DLLs that contain the business logic
for my core executable.
At the moment, when an error occurs in a DLL it is simply raised back
using Err.Raise through the calling procedures until it reaches the
core exe where it is handled and displayed to the user.

Due to the way the DLLs reference each other the error could have been
passed down through 3 or more DLLs and through twice as many
procedures, and by the time the error has been propagated back to the
core exe it is impossible to do anything sensible with it.

I have pointed out this flaw and intend introduce error handling and
display at the source of the error, i.e. in the DLLs themselves.

My senario is this however.

The core exe calls a function in DLL 1.
DLL 1 starts a database transaction and then calls a function in DLL
2.
DLL 2's funtion errors for some reason, and displays the error to the
user waiting them to press OK. When the user does, DLL 2's funtion
returns to DLL 1 which then decides to either Commit or Rollback the
transaction based on the return value from DLL 2's function.

The problem is that the transaction will have been open all that time
hence locking the database tables for other users.

As we know transactions should be a short as posible and we should not
place the user in control of their length.

Does anyone have any thoughts on this?

Thanks.

Chris,

Thanks for your reply.
The only way I could see this working is if you keep tabs on how many
transactions you have started at a particular time and then if an error
occurrs, you roll them all back in the function that caused the error.
Then make sure every function returns the fact that it has failed so it
can be dealt with.

Otherwise you need to raise errors back to the function that started the
transaction and have it to the Rollback and error display which is what
I was trying to get away from.

Any tips on how to determine how many transactions are open,

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

@@TranCount is a bit weird - looked into this.

nested / open transactions at that point (God knows why - maybe someone can
answer that?).

So.. you can't do any further tranaction stuff based on this value - the
only thing you can do is rollback ALL nested transactions.

Basically if any transaction fails, you must rollback all of them going up
the nested hierarchy.

At the very top level (a DLL I presume) you should be able to collect the
transaction failure reason - only need to really process the deepest level
error - and base your actions on that.

Rasing an error is *your* decision in whatever you create - generally, the
top level DLL should be able to take appropriate actions to make sure the
data is not corrupted and then return a status value (could be an enumerated
constant) or a success value. Raising errors to ASP pages is an absolute
nightmare so make sure you process possible failures after every actionable
call.

I can't really go much further without getting drawn into your development
methods and component.

Personally, I use the DLL for the transactions and leave the transact stuff
out of the SP's cos it's a lot easier to handle.

I hope this helps a bit.

Chris Barber.

Chris,

Thanks for your reply.
The only way I could see this working is if you keep tabs on how many
transactions you have started at a particular time and then if an error
occurrs, you roll them all back in the function that caused the error.
Then make sure every function returns the fact that it has failed so it
can be dealt with.

Otherwise you need to raise errors back to the function that started the
transaction and have it to the Rollback and error display which is what
I was trying to get away from.

Any tips on how to determine how many transactions are open,

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Reposted, since msnews.micro$haft.com seems to be "losing" certain posts!]

Perhaps you could use a technique similar to what Microsoft's been using
with their own database libraries -- Reserve Err.Raise for an "executive
summary" and roll your own "Errors" collection to hold a detailed trace.
I dislike the idea of hiding MsgBox calls or other UI within business or
data tier logic, because you never know if/when they'll be driven by an
automated process instead of by an actual user sitting at a workstation.

--
Joe Foster <mailto:jlfoster%40znet.com>     Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Perhaps you could use a technique similar to what Microsoft's been using
with their own database libraries -- Reserve Err.Raise for an "executive
summary" and roll your own "Errors" collection to hold a detailed trace.
I dislike the idea of hiding MsgBox calls or other UI within business or
data tier logic, because you never know if/when they'll be driven by an
automated process instead of by an actual user sitting at a workstation.

--
Joe Foster <mailto:jlfoster%40znet.com>     Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above        They're   coming  to
because  my cats have  apparently  learned to type.        take me away, ha ha!

Hi
Even I would suggest not using msgbox calls from a dll. You can do the
error handling whereever you want but the UI layer should be the one
showing all these messages. Of course, if you have a very custom dll and
are sure that its not being reused, then you can throw all these
concepts out the window. Till then, I suggest you separate the UI and
processing layers.

Warm Regards,
 Apoorva Tiwari
 Tata Consultancy Services
 www.tcs.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!