Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

David Williams wrote:
>
> Anthony Mandic writes
> >David Williams wrote:
> >
> >> But what if the user wants to be able to undo all the changes they
> >> made since they entered the screen?
> >
> > Er? Perhaps I didn't make myself clear enough. I'm not advocating
> > that you do the changes immediately. I should have said after the
> > user commits, you process the changes. Doing it concurrently is a
> > nightmare. Of course, there's no easy way to roll back after the
> > commit.
> >
> So if the user deletes 1000 rows, where do you store them. Not in the
> screen array because they are visible....
>
> what if the user deletes, then inserts a new row in the same entry in
> the array?

	Well, now we're entering the territory of screen/form display
	design. You'd have to decide whether you'd want to display the
	deleted rows by having them marked as deleted or not. Then the user
	would be at liberty to undelete or alter etc. A delete/insert
	is really an update - however this depends on the design of
	the key(s) and the business rules. In a audited system you may
	not be allowed to physically delete a row once its been
	added, you can only mark it as inactive (or whatever) and
	record details like who and when.



> >>   b) how do DBA indentify stale locks.


> >

> >       Check against existing user connections. I had a stored procedure

	True, but you'd have to have to have a very active system for
	them to do so so quickly. But you have more than one id to
	help - the OS's process id and the server's user process id.
	What's the likelihood of them both being the same ones again for
	the same user? I'd never seen the problem come up. But this isn't
	to say that it might happen.



> >       Data consistency/integrity. End users could pick up where they


> >       left off by finding their last lock. The app also stored current

> >       info on the client side (via files). This minimised data loss

> >       (critical when its a paperless office. Data came in over the

> >       phone).

	Yep, thats what was being guarded against. The app could have
	been termed overly retentive for this reason. It had to be
	as failsafe as possible. If a connection failed the app was
	smart enough to be able to reconnection when possible and
	continue. If it died it could recover from its client-side
	created files. It didn't give up without a fight. But of course,
	this didn't mean that we became complacent.

> Debug logs,screen messages.

        Yep, anything and everything.

> >> So does Informix 4GL, with startlog() function, all errors are t
> >> trapped by the Informix runtime library and logged.
> >
> > Good, thats the correct approach. Except that it only relates
> > to the server side of things. You'd have to rely on core dumps
> > (if on UNIX) and/or a debugger to debug a client app. Note that
> > there are two basic scenarios, the app failing or the app working
> > but doing the wrong thing. Which is harder to resolve?
> >
> Either is easy with debug logs. Switch on, get a trace, debug it.
> Most debugging can be narrowed down to one screen operation by the
> user, plaster with debug and that 's it.

	This is a point in time issue. But you have to work back thru
	the app to work out how it got into that state and how the
	data became incorrect. Often times it was as the result of
	some hairly written code in a module made by a programmer
	who either didn't have a proper grasp of what was required or
	didn't care.

	Of course, we've drifted off topic now. But while we're here,
	how many others have designed apps to guard against problems
	and what measures did they take?

-am Received on Fri Nov 28 1997 - 00:00:00 CET