Jul 1, 2008 11:32 AM Reply rshiplett in response to: Harry

I think it fair to say that typically Curl in an enterprise environment respects a separation of concerns: we rely on the server-side for the DBMS persistence (typically Oracle and DB2.)

The use of SQL on the client-side is most likely going to be for flexibility in working off-line and OCC to supplement Curl CSPD.

And there are other alternatives to explore (Rebol and TiScript both have interfaces to DyBASE) in those circumstances where a pointer-based DB may make more sense than relational for the business tasks of individual corporate users on the desktop. Rulebases are another instance that can afford flexibility to a 'fit' client.

Jul 2, 2008 2:48 AM Reply RMH in response to: Harry

Hi Harry,

If I understand your post, you are asking if Curl has the ability to connect natively to databases across the network in order to execute SQL queries directly. If that is the question than the answer is no. Actually, I think the answer is no for any RIA solution not just Curl.

As an industry we learned in the 1990's that connecting network clients directly to the database was a bad idea. Solutions such as PowerBuilder, Visual Basic, Gupta SQLWindows all provided the ability to connect natively to remote database and they eventually demonstrated that this type of architecture doesn't scale. That's one of the reasons the 3-Tier architecture became so popular.

Hardly anyone connects remote clients directly to databases today. Instead, network clients (be they desktop or RIA) connect to data services. A data service is a middle tier application that aggregates data and manages shared connections to databases. Sometimes the data service is built right into the database and many times the data service is provided by a middle ware solution such as Java EE or .NET or PHP. In either case, the network client connects to the data services using an application protocol (e.g. SOAP, POX, REST, etc.) which brokers requests for data from the database.

Connecting directly to a database from a network client is also a bad idea because of security. Anyone can disassemble your network client code and see how your database is architected and then execute queries against your database that appear to come from a legitimate client but are actually executing queries or other operations (deletes, updates) that were never intended for the clients. imagine someone deleting all your sales records or inserting approved invoices into your database for Accounts Payable.

We could probably add facilities to Curl to allow direct connections to remote database for executing queries but demand for this type of feature is small (your are the first I've heard ask for it) and the feature would deeply compromise enterprise security.

At one time we all thought that direct connections to databases from remote clients was a great idea - even the smartest advocated it - but experience in the 1990's demonstrated that it was a very bad idea that should be avoided at all costs.

I hope that helps.

Richard Monson-Haefel
VP of Developer Relations
Curl, Inc.

Jul 2, 2008 9:17 AM Reply cheese in response to: Harry

Hi Harry,

I can't say I completely understand your use case, so could you tell me if a solution like SQLite meets your needs?

As RMH indicated, RIAs typically communicate with a data services tier to obtain data. Once the data is retrieved, a client-side database like SQLite allows an application to perform SQL operations on the data it has locally. It isn't strictly an OCC-centric technology, although it certainly adds a lot of value in that regard. There are sure to be synchronization and persistence issues the application will need to resolve, but that's probably true of any situation where users are modifying data on the client.

CSPD stands for Client-Side Peristent Data, which is a convenient way for Curl applications to store small amounts of data locally (things like user preferences, application history, etc.)

Cheese