ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Suggestions for Updates >> End User Error Log
http://www.istechforum.com/YaBB.pl?num=1199298399

Message started by awaretec on 01/02/08 at 11:26:39

Title: End User Error Log
Post by awaretec on 01/02/08 at 11:26:39

Many times, when my users are having problems in a particular screen, they often "forget" to mention (or forget what it said) that a DBA error message had just popped up.

How difficult would it be to create a log file of date/time stamped error messages, similar to Event Log Viewer's (or even as a part of it, for that matter), on the client-side?

Title: Re: End User Error Log
Post by fast on 01/11/08 at 09:42:53

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.

Title: Re: End User Error Log
Post by RPCAdmin on 01/11/08 at 11:09:24

This is a great idea, if it is possible. What say Allen or Lynn - is it possible?

Title: Re: End User Error Log
Post by GasGiant on 01/11/08 at 12:01:13

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.

Title: Re: End User Error Log
Post by Lynn_Pantic on 01/13/08 at 18:06:36

Great idea but... Unfortunately, when an Error happens, it means that the program has (to some degree or another) gone beyond our control so I am not sure if there is any way we can do this. By definition by the time the error is on the screen, the program has misbehaved beyond the point that we can tell it to do anything. If we could, we would already have programatically told it what to do when this (whatever "this" is) happens.

Title: Re: End User Error Log
Post by kkmfg on 01/13/08 at 19:19:22

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...

Title: Re: End User Error Log
Post by GasGiant on 01/14/08 at 06:34:21

Hanh? No error logging? Output to screen only? Is TAS even a real language?

Title: Re: End User Error Log
Post by kkmfg on 01/14/08 at 08:05:33

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? ;-)

Title: Re: End User Error Log
Post by GasGiant on 01/14/08 at 10:01:39

kkmfg wrote:

Anyone up for some C# modules? Please, pretty please?

I'm not up to speed on C#, but it feels a lot like Java. I worked on Java full time for a year or so and had some training in C++. C# looks pretty good, but I don't hold out much hope of a project like that going smoothly.

BTW, I must be odd, since I can certainly name a lot more than ten languages. I think I've worked with about ten different versions of BASIC! I guess that's what you get for hanging around this stuff for thirty years.

Title: Re: End User Error Log
Post by kkmfg on 01/14/08 at 10:43:50

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....