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.

[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!