This was discussed elsewhere but, as is my custom, I'm reposting it here because this is the place for it.
 
I was reading through the API documentation on calls to wbtrv32.dll (the library Evo uses to interface with BTrieve) and saw that BTrieve does indeed support abortable transactions (at least in reasonably recent versions of PervasiveSQL). So, how about adding abortable transactions as a feature in Evo??? Don't know if TAS7i supports this or not but I hope it does. Other people have expressed interest in this sort of thing as well.
 
BTW, if you offered source code like DBA used to do then some of us (HINTHINTMEHINTHINT) might be able to either 1. Give more informed opinions of what is or is not reasonably feasible to do in Evo or 2. Do it themselves. Just a little more razzing about something I still don't fully support. (Remember *that* bloodfest? Shudder!) At least I can look at the old DBA source if I'm curious about the general way that things work.
 
As it stands maybe I can redownload Tas7i and look for myself to see if it supports transactions. Something as simple as starting a transaction automatically at the beginning of a long task and automatically committing it on successful termination would be great. There would be no user viewable change except in the case of errors where the transaction would auto rollback. It doesn't seem like implimenting that would be overly difficult.
 
(Update: Downloaded TAS and checked for myself. Yes, Tas7i does support transactions. Seems the support is pretty easy to add too!)

Sure thing, I'll learn TAS a bit and give it a whirl. Shouldn't be too hard to create a test app that uses it. I'd probably just have two code paths, one that starts a transaction, does some database work, and commits. Then one that starts a transaction, does database work, and then rolls back. Obviously one should update the database and one should not. Maybe a third path, one that starts a transaction, does work, and then dies. With no commit the database should still be left in a consistant state the same as before the transaction start. The third one is the real key... You want to know that if your machine locks up, catches fire, and explodes that the data on the server will still be consistant and safe.
 
BTW, what about it did not work? Did it just plain not correctly abort transactions? Did it not actually do the correct all or nothing behavior? Never commits properly?

Sorry to hear that. We've had some *weird* things happen with crashing programs as well. I hope that Tas7i really does support transactions fairly well so that ISTech can put transactions into critical places.