Hi All-

The applications I'm working on have full and restrictive database transactions.  The full database transactions have been in the applications for years.  (FlashFiler versions.)  The restrictive are new.  There are some tables I don't necessarily want to be part of a transaction.  The data is of lesser importance, and if these tables should force an error I'd rather just cancel the insert/edit and continue with the transaction. A table maintaining form positions is an example.  An ErrorLog table is another, though that is more complicated. I think that would involve nested exceptions, and that will probably be more testing than I can do right now.

The transaction exception code is all in one place for each transaction
My typical Rollback is, basically,
 on e:exception do begin
   Store the message  // this may be unnecessary, or sometimes unnecessary
   Rollback
   cancel edits/inserts
   Show the error message

I'm experimenting with trapping exceptions for the non-critical data in the routines where they're located, meaning there would be a second exception routine in play. These routines are located in shared code, as they're common to multiple applicatios

The basic transaction exception is as above
The local exception would be something like:
 on e:exception do begin
   Store the message
   if (LocalTable.state in dsEditModes) then LocalTable.Cancel
   if TableInTransaction(LocalTable) then
     raise
   else
     Show the error message
 
This seems to be working fine, but I have concerns.  Primarily, where and when to cancel the edit on the local table.  If another error is introduced I suspect problems would arise. I have always done the Cancels after the Rollback. This is different.

I could add the secondary tables to the Tables array. These tables are frequently used outside of transactions, but they are included for all the full database transactions. I see some potential problems with that, which is what I'm trying to avoid.

I'm not at all sure if this post is clear. Hope it is.

Thanks,
Judd

Judd

Its not something I've done so without actual code to try it out I'm guessing.

I think the main concern is what you do after cancelling the edit / insert and if you're using a construct like

   if (LocalTable.state in dsEditModes) then LocalTable.Cancel

in the transaction exception cancelling.

If you have then unless you try and write to the table involved after taking it out of edit I think you should be safe.



Roy Lambert

Thanks, Roy.  Some encouragement is what I needed before live testing.  So far it seems to hold.  

I probably saw your post a day or two after you posted.  Some non-work issues.totally took over, and I forgot to acknowledge.

Next up will be writing an error message to a table instead of displaying it, under certain circumstances.  I'd love to get something like that working.  Worth trying at least.

Judd

>Next up will be writing an error message to a table instead of displaying it, under certain circumstances. I'd love to get something like that working. Worth trying at least.

That one is a fun one. For the majority of errors it will be fine BUT if the error is a loss of connection or some nasty problem with ElevateDB you could end up going in a loop. My decision was, for major errors with my email subsystem, to write to a text file.and if it existed to display it the next time anyone logged in.

Roy

"BUT if the error is a loss of connection or some nasty problem with ElevateDB you could end up going in a loop"

Something like this is what I am concerned with.
I have an errorlog I want to write to when messages are deliberately not displayed.  Usually I just want to display an error, and have users email me.  Which they do....sometimes.  In early testing there were some errors which left files or records locked, and left me unable to figure out exactly where and what happened.  While I'm 99.9% sure all transactions are in try-except blocks, I've typically ignored that for simple edit and post.  When the apps are running real time, and I have time, I think I'll work more on global OnEdit and OnPost routines .If the error happens while in a transaction to a table in a transaction, I'll raise, rollback and display the error.,  But it the error is on a table not in a running transaction, I'd like to write it to the errorlog and continue with the transaction if possible.  If not possible, or the errorlog write causes an error, I'll have to determine if best way to proceed.

As I'm writing I'm remembering the simplicity of locking the whole database.  

More ideas are popping up, and they're definitely not thought out, so I won't bother mentioning them. Excepting the text file idea.  If I was to try something like that, the users could read it at their workstation when they enter the system again, and copy it to an errorlog table I can read.  Um.  Something to consider. Interesting idea.  Thanks

Judd



<<When the apps are running real time, and I have time, I think I'll work more on global OnEdit and OnPost routines>>

Rather than that look at subclassing the table and query components. Its easy enough to do now that we have edbcomps. The main things you'd need to modify are the OnPostError (which is Delphi's) and possibly the InternalPost routine. I'd also suggest having an errortable property so that you can specify it on an application by application basis.

If you want to go down that route and need help let me know.

Roy Lambert

Roy Lambert wrote:

<< Rather than that look at subclassing the table and query components. Its easy enough to do now that we have edbcomps. The main things you'd need to modify are the OnPostError (which is Delphi's) and possibly the InternalPost routine. I'd also suggest having an errortable property so that you can specify it on an application by application basis.

<< If you want to go down that route and need help let me know.


Hi Roy, i'm aldo interested in how you're doing the OnPostError and InternalPost changes for catching errors etc. Any example codes available?
--
Yusuf Zorlu
MicrotronX

Yusuf


>Hi Roy, i'm aldo interested in how you're doing the OnPostError and InternalPost changes for catching errors etc. Any example codes available?

Sorry, no code samples of that since its not something I've done with my subclassed components. Those are in the binaries ng and will give you some idea.

Message-ID: <52BA3A3F-C46E-4012-9985-09B894FAFF3B@news.elevatesoft.com>
Date: Sat, 30 Nov 2013 12:51:42 +0000
NewsGroups: elevatesoft.public.elevatedb.binaries
Subject: Roy Lambert's Tnlhxxx stuff

I'm willing to extend my components if you and Judd give me some idea as to what you would want in the log table - I need to collect a superset of requirements so that everyone is satisfied. I'd also need to decide on some rules like - must be in same database / session as the table being monitored.

Roy

Yes, Roy, I am very interested in this.  I'll do my best to keep up. Two things come to mind, and they're related.  
 It has to be something simple for you to create, for obvious reasons.
 It has to be relatively simple for a mediocre programmer to maintain.

The second is based on my own experiences with making components that were great for me.  Time saving and easy to incorporate into my apps.  But, unfortunately, not easy to move into a different environment.  The problems were that I don't work with creating components enough for them to be second nature, and I'm not exactly great at documenting.

" must be in same database / session as the table being monitored."
This is not a problem for me.  I don't foresee adding a second database unless there's no intersection with the current database.  Of course, lots of things I've never foreseen have come to pass.

Here are the fields of my ErrorLog. I think you're asking for something like this, though I'm not sure:
 RecID: a unique autoinc field
 FileKey: varchar(15); usually the table, though sometimes it's partially descriptive; could be bigger
 RecordKey: varchar(15); usually a unique field from the table;  sometimes partially descriptive; could be bigger
 DateTime: timestamp
 UserNum: integer
 Msg: varchar(128);  I'll probably change this to a text memo at some point

I don't think the field sizes are really of interest here, but....

If you want to go ahead with this, and I can be of any help, please let me know.  I can provide an e mail address here with one of those awkward spelled out method if you'd like.
Judd

Judd / Yusuf / anyone else interested

I started thinking about this and came to a conclusion - the requirements are going to be very similar for everyone but are pretty likely going to be different for everyone as well.

eg Judd has a user number - I have a varchar(5) user id


Whatever I developed, unless inflexible (er error log table name and fields), would need some user customisation and would need a few extra properties for tables / queries (or some globals).

So what I'd suggest is just using a global OnPostError event that can be hooked on to any table that needs it. I'll put a template together based on Judd's fields and post it in the extensions newsgroup. It'll take a few days but not massively long.




Roy Lambert