Jan passed his thoughts on some of this to me privately. I'm posting my response to the list because (a) I think I know him well enough that he won't mind, and (b) to save any else the time of correcting me regarding selecting all columns of a single record.
In our projects, we set in MySQL a single password and priviledges for the project, and handle the user password logic in our own programs.
But don't you have to create a user table in the DB with one entry for each user? Or can the same user be active from more than one work station?
Actually, 'SELECT * FROM customers' will give you all the customers, simply because you hadn't specified a WHERE-clause in your query. The * means 'all fields'. If you execute a 'SELECT * FROM customers WHERE customer_id=123456' query, you will get all the fields for that one customer ID.
Thanks for correcting me. As I noted, I couldn't believe there was not syntax for this; but I didn't see it in the manual and no one had corrected me up to now.
Though that can be easier for some type of projects, especially if you're building a hierarchical database, it's easier to remember a name than a number.
I agree; but just because it's easier doesn't mean it should be a requirement. Should xTalks not allow references by id or ordinal?
Plus, you can swap column sequences and insert new columns for greater consistency without bringing existing apps to your knees.
With SDB, I see no situation that causes the existing portion of the record format EVER to be modified. Since fields are variable-length, changing a field size does not require changes in existing apps' logic [though the size of the field in the window might change]. New fields can all be appended to the end of the record: their position in the record has no relation to their position in the window. Obsolete fields can be left in the record definition at a cost of one extra delimiter character. It is true that the record field numbers and their corresponding windows' field numbers may no longer be in the same order--they were not likely to be in a one-to-one correspondence anyway.
That being said, I certainly intend to build a data dictionary for OenoLog and reference fields by dataName.
However, someone with a simple database structure can manipulate packing fields into a record and unpacking them again directly in the stack logic and never have to create user- or data-definition tables in the db. Tell SDB Server, "file this record with this record type & key; return it when I pass this record type & key", and the server needs no information from the db about the user requesting the service or the structure of the record.
--
Rob Cozens CCW, Serendipity Software Company http://www.oenolog.com/who.htm
"And I, which was two fooles, do so grow three; Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631) _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
