GREAT idea!  A tweak might be to send the error log to x email account too.  This way it'd be automated versus reviewing users log_file on a daily basis.

Oooh, interesting. If a log file with the username was created or appended in a folder on the server then you could delete it when you are done reviewing it. Then you could look in one folder and see who has had what errors recently, if any. Not easy, but should be doable.

That may be so but it's only true because of the use of TAS. In most programming languages you most certainly CAN output the sort of end user error logging that people are requesting.
 
Sooooo, the bottom line is that the best person to bug about this is Tony at Addsum as he can modify TAS such that it would support error log dumping. But good luck on that...

The short answer is no, not really. I've seen a list of over 6000 programming languages, 5990 of which you will not have ever heard of. Guess what, TAS is not on that list. It's not on ANY list I can find. It's got to be the most obscure programming language ever used for a commercial product. I think you could find more people who know ALGOL or scheme or B or ADA than you could who know TAS.
 
What irks me is that as bad as TAS is I still don't know if I can really bring myself to say that they should try to port to something else. There seems to be some nasty things in the codebase that could use work first. Although, a port would be a good time to fix those things. And it could be done a module at a time. Anyone up for some C# modules? Please, pretty please?

Heh, yes, I could name more than 10 as well. The 4 or so I mentioned are quite obscure these days though (some of them used to be more popular.)
 
Anyway, C# is sort of C++ and Java mixed together. It's more object oriented (like JAVA) and has automatic memory cleanup (like JAVA) but it's based on C++ and one can code in C# and make it almost indistinguishable from C++. Personally the majority of my programming experience is in straight C but it's not so well suited to modern GUI applications. I think that C# is a good compromise between power and ease of programming.
 
More on topic, a C# port of any of the Evo modules wouldn't be the most straight forward thing that anyone has ever done. The biggest hurdle is one of differing paradigms. The TAS/BTRIEVE combo is geared at a record manager mindset. You access records one at a time and make function calls on the record level. Modern day design tends to favor a more broad view of the database where data accesses are done in larger batches via SQL commands. It's possible to use cursors to approximate the btrieve/tas behaviour but it's suboptimal. If one were to do a port it would be much better to go for broke and do it properly. This adds extra porting complexity and extra areas for mistakes (not that programmers EVER make mistakes when coding.) Add to it the natural tendency toward spaghetti as a project ages and you've got a real mess on your hands. This, of course, is partly what happened to DBA. You just can't throw the old code base away and expect to be able to produce something on par with it overnight. Which is why I somewhat jokingly suggested it to be done in modules. It still might be a nice idea....