Probably the first decision that should be made is to determine how you will be persisting the three data types that SQL designer uses. Persistence of these data types (they are all XML formatted text documents) may be managed by your host application, or, you may have SQL Designer persist them directly on the file system, supplying it with path and file naming information.
If you will use your database to persist query designer information, we recommend that you use a single table with columns such as the following:
GUID : VarChar(36) - A key column that holds the GUID for the schema or query definition
DisplayName : VarChar(50) - A friendly name by which the user may refer to a query or schema.
RecordType : Integer - Specifies the record type being stored (Schema, Query or Global Settings)
Data : Text - Holds the XML formatted string data that is the definition of the schema, query or global settings
SQL Designer provides the methods to construct queries and schemas directly from a string that would be stored in the 'Data' column of this table. Additionally, when SQL Designer requires you to supply a schema or query, it will reference that item using its GUID (cSchema.SchemaGUID, and, cQuery.QueryGUID), making it a simple matter for you to retrieve the record by matching the GUID column and provide the content of the 'Data' column in response to the SQL Designer event.
Using the file system is another alternative for persisting the schema, query and global settings information. The sample application uses a specified directory to save the schema and query files, using friendly file names for the schema and query definitions and reading each file to determine the GUID when the application first loads. An alternative approach would be to use the GUID for the file names and read the files to obtain friendly names for display purposes.
Either way, this approach is also directly supported by SQL Designer as it has constructors and methods on the cSchema and cQuery objects that support SQL designer directly reading the files from the file system as instructed by the host application.
We recommend that you examine the sample application's approach for additional guidance on using the file system for persistence of schemas and queries.
You may of course use any persistence mechanism for storing SQL Designer's data. The main thing to remember is that user's are going to need to specify queries to load using friendly names that will be meaningful to them and SQL Designer is going to need to obtain query and schema definitions from you by referencing the object's GUID.