The command line utility for running SQL scripts is called "isql". You'll find in the "bin" directory of your Firebird installation. But if you intend to use "embedded" you might want to look at alternatives methods (after all, the value of embedded is that you only ship one extra DLL). Specifically, look for a way to run a script from Firebird's ADO.NET provider. If there's no such method (those I doubt it - running SQL scripts is such a basic thing), you've still got options: You can "run" the script semi-manually OR you can go for the whole database file approach.
If you want to run the script manually: Take a look at an full metadata extract for your database. You'll notice the full script is actually built from smaller blocks. Each SQL command is separated by an ";" char (just as Delphi statements). One SQL command may be several lines long, but it will eventually end with an ";". You can separate the full script in smaller bits and run each command in sequence, using FbCommand.ExecuteNonQuery. The end result will be the same: you'll have a new database. One note those: this routine will need to be twicked a bit when you start using stored procedures or triggers, and that's because you'll need to cope with alternative terminators (Firebird's SQL includes the ability to change the standard terminater ";" to anything you want, usually to "^". This is necessary because a stored procedure itself will contain lots of ";" chars and the scripting thing needs to know where the procedure actually ends). For simple database the method would work just fine. In the end, you might want to go for the full database file approach for a few applications, then switch to the script when you'll feel more comfortable with scripts. -- Cosmin Prund Robert Meek wrote: > Now you'll know why I hate making assumptions and would rather be > told straight out about such things! I thought from what I'd read, that the > Metadata was a series of attributes used by the Schema! But once I read > your explanation below and went back and took a look at my already created > tables, and extracted the metadata, I finally understood where my thinking > had gone wrong! Thanx for straightening me out on this! > My reasons for wanting to have the application itself create a whole > new database on order, such as when a new user logs on to the system and > runs the app for the first time, is that in Delphi this meant everything was > hard coded in my exe and there was no worry about corrupted or missing > files. But since I can now no longer do things that way, I still think that > including the metadata and running it upon a create new database command > will be the best overall method to use. Let me ask you though. What > exactly is necessary to run the metadata and create the database. And is > there a command-line order I can "put" together on the fly so as to instruct > that the new database for the currently logged on user is named and created > within the directory wanted? Then of course, anytime in the future that > same user logs on, HIS or HER own database will be opened up by the > application when run. Down below you say that one of the alternatives for > running the script is via the command-line, but what is needed to run it? I > would rather not have to include a copy of a management tool with the app, > and in many cases these will be self-installed and my only contact will be > via phone or e-mail. So if a third-party exe is required to run the script > in the first place, and it's not something that either is or can be included > in my exe, it would appear that the other method, where a full copy of the > database is included as a compressed file along with the setup and then > accessed and copied over to the named directory when ever a new database is > required. > You have to understand the kind of people I'm dealing with back > here. I'll soon be writing an upgrade to a training application I created > pro-bono for the County Dev Assoc., which provides trained illiterate and > mentally challenged temp employees. They now want me to expand on the > training application which did and will continue to include a separate > database file with multiple tables in them for each trainee to use as they > learn how to input and retrieve data. Most of these people cannot even > write their own names, but put them in front of a keyboard and show them > what, when, and how to do something, and they take to it like a duck takes > to water! It's really something! But the most important thing about it is > not that they CAN handle the work, but that doing so gives them a feeling of > belonging and value that they would never otherwise have! Giving a little > of that to some of these people is more than worth the time I spend putting > such an application together! > > _______________________________________________ Delphi-DB mailing list Delphi-DB@elists.org http://www.elists.org/mailman/listinfo/delphi-db
