and now that you had a few minutes to play with that file it also shows some of the problems that Base poses to utilizing these features in the embedded data model and the odf file structure.
For instance - looking at the query again, the table name should be invalid, as I said. Well, maybe I used the table filter property to hide a table named 'biblio'. If you check you will see that I did not - but that is a feature that is useful, particularly with remote data servers. Here are two more things to try with the file: Switch to the table section. Select the Biblio table and launch the form wizard. No fields, can not connect.... Try the form wizard against the query. Voila - column names and it looks like the biblio table. Go ahead and save this form. Open it - drat no data. Open the form for editing. Open the property manager for the MainForm component. Change the data source from query to SQL Command Enter this for the command SELECT * FROM MYSCHEMA.BIBLIO save the form and open it - data. Read only data - problem one. I used a custom schema, added via the SQL window to store the actual data table. This is a nice technique for business logic table (lookup tables) but currently Base GUI controls will only use tables in the default 'PUBLIC' schema. As for the 'biblio' table - the ghost. Well, this was created by issuing the command: SELECT * INTO 'biblio' FROM MYSCHEMA.BIBLIO Temp tables are not visible under Base - a good thing. Unfortunately there are other issues with Base and temp tables, GUI controls again being the location, but they also can be used in scripting. Now - at this point one thing that is not possible is to hide this type of information from anyone that can actually open the ODB file with an archiving tool - for if you did this, then will find the DML commands for these 'tricks' in the database directory. But for keeping nosy users out - well. Drew
