Import from a Database

If you already have an existing system with a SQL Server database then you can jump-start Xomega object modeling by importing the model from the database using this generator. It will build the objects and fields from the corresponding database tables and columns and will define the logical types for the fields that will preserve relationships between objects. Prior to running the generator though, you need to make sure you pre-configure the model as described below.

Import Prerequisites

The generator will try to map the database types to one of the existing Xomega types or, if not possible, will define a new type that derives from one of the existing types. Therefore, before you run the import you may want to make sure the existing types' configuration is consistent with your current system standards. For example, the boolean type maps by default to a SQL Server type bit. However if the standard for your current system is tinyint to store a boolean, then you should update the Xomega type to map to tinyint, so that it can be properly identified by the generator.

By the same token, the generator can identify groups of fields that match one of the field-sets defined in the model and use a reference to the field-set instead of those fields. If all or most of your tables, for example, have a set of standard columns, such as the user who created the record and the creation time stamp then you can just define such a fieldset in your model first and it will be automatically used by the imported objects. If later on you will want to also add the user who last modified the record and the last modification time stamp then you could just add them to that field-set definition and they will be automatically included in all the objects that use that field-set.

What you should also be cognizant of is that Xomega subobjects are inseparable from their parent objects and require a cascading deletion whenever their parent object is deleted. As a result, for the Import generator to define objects as subobjects their foreign key relationship to the parent object should have cascading deletion and the columns on both ends of the relationship should have the same names. If you would like some tables to be imported as child objects then you may want to consider updating their foreign key relationship accordingly before the import.

Import Configuration

When importing the model from a database you should first of all define the database connection for the generator. You can do it via the Database Connection Configuration dialog that pops up from the generator's Properties page. In that dialog you should specify an OLE  DB connection string to your database, which Xomega will validate and use to read your database metadata. On the next tab of the dialog you can specify which database tables you would like to exclude from the model. Next, the system will try to determine if your database names are case-sensitive and will set the Database Case to CamelCase or your choice of UPPER_CASE or lower_case respectively, which will be used for generating tables for all new objects as well.

It makes sense to save this database configuration as default project settings, which will be one of the options in the dialog, so that all other database-related generators could reuse the same settings. This way, for example, the database change script generator won't try to remove the tables that have been explicitly excluded from the model. If you save it as a default configuration then it will be available in the project Properties page and the corresponding generator properties will be set to the 'Use Project Setting' value.

The generated Xomega files will be automatically added to the project under the folder designated by the Output Destination property. You can leave it blank to output to the project folder but you may want to consider generating it in some project sub-folder initially (such as the default Import/ folder). This will allow you to review the generated files and if you realize that you need to make some of the prerequisite adjustments then you will be able to safely clean the generated output without affecting any of the existing files and rerun the generator. Keep in mind that the Clean or Regenerate commands will just delete all files in the destination folder that match the output patterns specified in the following property. It is recommended to keep the default Output Patterns for this generator (**/*.xom), which refers to all .xom files in the output destination directory and its subdirectories, since this is the default extension for Xomega Editor.

Finally, you may want to configure additional generator parameters that allow you to preserve certain database names in your model. This can make your model significantly larger, but it will ensure that the model objects and fields always map to the same tables and columns even if you rename any objects or fields in the model. The table and column names for new objects and fields will be derived from their names unless you specifically configure them to use certain database names.