RS>> SQL is a bit different and in a sense is just a standardised

 RS>> language, usually used between systems. Nothing much to do with

 RS>> users. Sure, you can have the user writing SQL commands manually

 RS>> which produce a result. But the more common thing would be to have a

 RS>> say client server approach were the communication between them is

 RS>> with SQL and the user never actually sees any SQL at all.



 PM>> SQL is a database query language, it has nothing to do with

 PM>> client-server.



 RS> In the strictest legal sense thats true.



In *no* sense is SQL client-server. Certain database systems may be able to
ship the query to another machine, but this has nothing to do with SQL and
could be done equally as well using non-SQL calls. It certainly isn't, as
you claim "...in a sense is just a standardised language, usually used
between systems"



 RS> But in practice SQL IMO shouldnt be used as a language used by the

 RS> user to communicate his wishes to the system in say a message reader.

 RS> The system should be say offering a set of common reading modes,

 RS> sequentially by area, all the personals, all the messages with a

 RS> particular subject. The user just specifys the data if necessary and

 RS> the database system may actually use a SQL query to do the work, but

 RS> IMO its medieval for the user to be actually writing the SQL himself

 RS> for stuff like that. Its lower level stuff which is best concealed

 RS> from the user.



Nobody is talking about getting an end user to pound away entering SQL.
What we were talking about is the user interacting with the application (as
he does now) and the application issuing the SQL. I don't consider SQL to
be a language that the average end user should be using (it's way too
dangerous for that), but I do consider it desirable for a programmer to
know and use it.



 RS> Corse the other consideration is the use of SQL as a standardised low

 RS> level layer which in theory allows portability. Thats true in theory but

 RS> the PC world doesnt work too much like that.



Depends on your definition of portability. Unless your implementation does
something *really* strange, then SQL is pretty portable.



Besides, portability isn't the only reason for using SQL. The biggest
reason is the ease of querying databases. Even simple SQL can save you a
lot of time coding calls to the database engine.



 RS>> There isnt even much point in SQL in the situation where you have say

 RS>> a database which contains all the messages and say a full database

 RS>> system which is used for reading the messages by the user. In this

 RS>> particular case I cant see SQL gets you anywhere in particular.



 PM>> This is exactly when you *would* want to use SQL.



 RS> Nope, normally that isnt done with PC class databases and its normally

 RS> only used in a client server config where the PC database client does all

 RS> the user interface stuff and then talks SQL invisibly to the user over

 RS> the client/server link. The results of that query are then presented to

 RS> the user.



Regardless of whether the database is local or remote, on a PC, mini, or
mainframe, SQL is the preferable way of accessing even something so simple
as the database Paul wants to build.



Again, we're not talking about users having to enter the SQL, although you
may want to provide the option for the power users.



 RS> For example with Paradox on the PC where all the user interface stuff is

 RS> done, it itself talks SQL back to the database server. The user isnt

 RS> normally talking SQL himself in the better implementations.



 RS> For example in a motor registry environment the staff are just form

 RS> filling and the client apps can indeed be talking SQL back to the

 RS> database server. But the user isnt seeing any SQL.



Yes, but the *rest* of us are discussing the benefits of a programmer using
SQL to access the underlying data.





Paul



--- GoldED/2 2.42.G1114