> Imagine you had a project that runs SQL scripts both
> locally (Windows) and remotely (Unix server).
> You would want to allow your Windows users to
> - run local SQL scripts to extract tables from the SERVER
> - manipulate the extracted tables LOCALLY
> - run SQL scripts LOCALLY to process the extracted tables
> You would also want your project to target an as wide as
> possible audience of corporate financial administrators.
> What DBMS and SQL flavour would you go for? Ideally, only
> one dbms that would fit on servers and PC's.
The processing techniques that are appropriate on the client side and on
the server side are simply not the same; therefore you will wind up
using a combination of products. But it is desirable when the client
and the server both have SQL functionality, are able to perform
so-called "heterogeneous queries" where both the client and the server
can participate, and so on. That way both computers can be what they
are: real computers.
The Microsoft Access product is particularly nice in this regard because
its Jet database-engine (which rumor has it may go away!) is SQL-savvy
and works well with ODBC or DAO to a client/server database. You can
use the whole schlotszky, which is rather large, or you can simply use
its engine in conjunction with other products.
Books such as "Inside ODBC" and the reference manual for MS Transaction
Server 2.0, as well as "Client/Server Survival Guide," may provide you
with some useful insights.