Hi there

The differentiator, i think, is to do with connectiveness and persistence of the connectivity. In client server the connection is made and persists at all times for that client, unlike "network" computing which, but its nature, is stateless. In stateless, I am meaning that you cant persist a a bunch of screen interactions in sequence within a transaction like you can do in a client server connect. For example, I open the clientserver app, its opens a db connect (pooled), we open a form, a transaction may begin for arguement sake and 3 screens later and commit it all. In the stateless env we cant persist the transaction (easily) between such screen re-renders. The db connections come and go between calls along with calls to the business tier. As such, your locking/transaction models and design a quite different. This is a trap when porting client server apps to the web. What I see happen in the port, is applications to deliver contents via the browser, but utilise a java based or web-form type connect that "simulates" the client/server senario. The Oracle Form 6 webform type stuff is a classic example of this sort of thing going on, where by a click of a button the developer tool can create a .exe/fmx based client/server app rendered for the web or runs from the persons pc and associated exe's.

I better get back to work, just some thoughts.. there are many other issues to consider.

🙂

Cheers

Ck

Chris Kempster

http://www.chriskempster.com

Author of "SQL Server 2k for the Oracle DBA"