Re: ODBC (was RE: Green screen - it's time is over )

> In a client/server environment (be it message based or shared
memory, or any one of a
> dozen other strategies...) you have moved processing logic into
the client part, and that
> part is just as likely to be in error as a server module that
does the same logic. In other words,
> moving the logic doesn't make it correct.

Yeah, what he said.

> Secondly, even if *most* of the programs in a client/server
environement would be
> correct, either through an insensitivity to dates like you
mention, or because of some
> other reason, you don't *know* that until you *examine* them. In
short, you haven't
> really avoided any work, and in many cases, you have made it
more difficult, since Client/Server
> programs often escape the scrutiny given to host based programs
in terms of standards and
> testing.

Yeah, what he said again.

and also, since part of the logic is in one place, and part in
another, you really have to have someone who can read both types
of programs at once to debug it. There can be interaction effects
between the layers.

My preference at this point is for client server with SQl for the
database access and web for the client, with no custom programming
in the clients (in other words, you can have little JavaScript
enhancements, but they have to be the same for all client
invocations, with no direct data access.)

Whether that SQL is on NT , are remote to an AS/400 server, is
secondary.

The browser paradigm is so universal, I have even experimented
with web-style applications as standalones, using VB and the DHTML
object. Mixed results, so far.