Frequently Asked Questions
Here you will find questions about DBUpdater32 and DBUpdater Component.
DbUpdater32 is our Free database schema update tool.
DBUpdater Component is a commercial project and need a licence to be used.

What are the license conditions?

Do I have to pay a fee for each database I want to synchronize?

How much will it cost me to upgrade to the latest version?

I’ve a partnership licence, what can I do to get the latest version of DbUpdater?

If two tables are identical except for column order, DbUpdater will change the structure?

If the database does not exists, may I use the component to create the database?

What are the Provider settings? Can I save them?

Can I select which database entities to compare?

May I define an update policy for all customer database?

I’ve defined an update policy, but one customer has a situation in which I need to define a “special” policy. What can I do?

The customer database contains a table that is no more used. DbUpdater deletes it?

Is it possible to exclude from the delete policy some special custom tables not present in the original database schema?

Do I need to use the special prefix for all entities of the custom table?

I’m a little bit confused between Producer and Updater settings. Why you need both?

When I roll back an update routine, some sql statements are not rolled back. Why?

Can I save the result of Database Comparison?

How do I change the Producer schema directory that DbUpdater uses?

How can I hide the Console and Progress Info Windows during the Comparer phase?

Is it possible to localize the console messages?

Is it possible to localize the progress window messages?

Does DbUpdater work with Microsoft SQL Server 7/Oracle?

I use SQL Server 2000 as developer. One of my client uses Sybase Adaptive Server Anywhere (ASA). May I use DbUpdater to Synchronize it?

Can DbUpdater copes with very large databases?

What happen if I insert a primary key or a unique key and there are conflicting record in the custom database?

What happen if I insert a foreign key and there are conflicting record in the custom database?

During Updating phase I got errors. What can I do?

May I need to install something in the client machine?

Q: What are the license conditions?
A: DbUpdater32 is free. For other products, please, click here to see licence conditions for all our database products.

Q: Do I have to pay a fee for each database I want to synchronize?
A: No. DbUpdater32 is free. The component is a one time licence. You can do what you want and use it for unlimited number of users/databases/customers.

Q: How much will it cost me to upgrade to the latest version?
A: If you have a partnership licence, you will get minor upgrades for free. For more information, please, click here to see licence conditions for all our database products.

Q: I've a partnership licence, what can I do to get the latest version of DbUpdater?
A: Nothing. As a partner, Era Soluzioni will inform you for new releases and will send to you links and all you need to update the product. For other kind of licence, you are asked to check periodically our web site.

Q: If two tables are identical except for column order, DbUpdater will change the structure?
A: No, DbUpdater verifies the table structure regardless of column order.

Q: If the database does not exists, may I use the component to create the database?
A: Yes. A special property allows you to define what to do when the database does not exists. DbUpdater can:

•  raises an error

•  creates the database

The second scenario is the one you need. We use this setting in the component included in the installation routine. We simply asks the customer provider and the component will creates the database from scratch. To get this behaviour, set the property "AutoCreateDatabase" to true.

Q: What are the Provider settings? Can I save them?
A: You can think of the provider settings as a project. For each database you can define its specific options (connection string, update policy, folders, .) and save them in a file. Each time you need to synchronize that database, load the settings and run the schema extraction. The component will prepare all schema information required to synchronize database together with the definition of the update policy to apply and put these resources in the specified folder ready to be delivered to customers.

Q: Can I select which database entities to compare?
A: Yes, this is a part of the updater policy. You can define the category of entities to update, by choosing upon table, fields, indexes, etc. as well as the entities to delete when they are no more available in the source database schema.

Q: May I define an update policy for all customer database?
A: Yes. This is the normal case. The update policy defined in the project will be applied to all the destination databases. Normally, for each database, we define two projects:

•  installation project. This is a special project we use for installation procedures. When the database does not exists, DbUpdater is able to create it from scratch. For this special purpose project it is important to define (and deliver) also the content of the base tables.

•  update project. The normal project used periodically to synchronize customer databases.

Both projects share the same database schema information. The difference is in the update policy delivered with the schemas.

Q: I've defined an update policy, but one customer has a situation in which I need to define a "special" policy. What can I do?
A: The only think you have to do is to override the standard policy defined in the database project. To do this, simply edit the "DbSchemaUpdater.xml" file and set the specific option you need to change. For example, if you want to make a backup of the database and the standard setting don't do that, edit (or creates it) the and write the following line:

  < BackupBeforeUpdate > beYes </ BackupBeforeUpdate >

Q: The customer database contains a table that is no more used. DbUpdater deletes it?
A: Yes and no. Entity and record deletion are the most sensitive operations because they can remove from database information owned by the customer. On the other hand, if the original database does not handle anymore a table this means that its content is no more useful. Deletion policy is defined by a set of options that must be careful set up. The "TDeletePolicy" class allows to define all these behaviour by means of a list of properties.

As a DBA or Developer team member you can establish if DbUpdater must delete or not database entities. For example, you can decide to delete fields and indexes no more used but not tables. In this example set the following value

DeleteTables := beNo;

DeleteFields := beYes;

DeleteIndexes := beYes;

Q: Is it possible to exclude from the delete policy some special custom tables not present in the original database schema?
A: Yes, not only for tables, but also for fields, indexes, and every other kind of database entity. You have to take care of naming the special entities you want to exclude from delete policy with one or more special prefixes. Then, in the project setting, you can define a list of prefixes used by DbUpdater to filter entities for delete policy. For example, we use the prefix "ERA_" or "CUSTOM_" when we need to allow the end user to create new tables/fields. Then, if the user defines a table named "CUSTOM_Employee" or a field named "ERA_LastName", dbUpdater does not delete these entities even if the delete policy is enabled.

Finally, you can define special prefixes also for one end-user: DbUpdater uses the directives from producer as a default behaviour. If you want to change the general behaviour for a specific customer, you can define the desired behaviour in the "DbSchemaUpdater.xml" file setting of TEraDbSchemaUpdater object.

Q: Do I need to use the special prefix for all entities of the custom table?
A: No, if you define a table with a special prefix included in the "PrefixesList" property then all entities related to the table are not deleted. This applies for table fields, indexes, constraints, etc.

Q: I'm a little bit confused between Producer and Updater settings. Why you need both?
A: As a newly user, forget the Updater settings and concentrates to Producer settings. These settings allows you to:

•  define folders where to save schema information.

•  define update policy (make backup, delete pending data, use default owner, .).

•  define delete policy

The first kind of settings is used only by the Producer and for project management purpose. The other two kind are used by the Updater object and are included in the database schema information to be distributed. We name these settings are "Directives from Producer".

To clarify this point, remember that DbUpdater works in three steps:

•  Producer, generates schema information for source database

•  Comparer, compare schema information with the target database and generates sql statements for synchronize the latter

•  Updater, executes the sql statements.

Given this three steps task, when you cannot run a live database synchronization, you can run the Producer and then send database schema and policy information. These resources will be used by the Comparer and the Updater.

Got it? Well, now let's discuss the Updater Settings.

They are used in special situations because in the normal scenario, the "Directives from Producer" contains enough information for Comparer and Updater. To clarify the concept, imagine the following scenario:

You are a software farm and you need to synchronize all your client. Of course, you will define a DbUpdater project and careful prepares the update and delete policy for all database entities. Say, or example, that you want to keep clean the client database so the delete policy contains the option to delete unused table. Then save it. When you need to update, simply load the project, run the schema extraction and pack all. Now you discover that a customer uses your database to store other related information and creates a new table. What to do?

Simply, override the "Directives from producer" by define a "DbUpdaterDirective.xml" file. This file contains special customer settings. In the example above, simply insert in the file the following setting:

  < DeleteTables > beNo </ DeleteTables >

And the Comparer and Updater will no longer deletes the unused tables.

Q: When I roll back an update routine, some sql statements are not rolled back. Why?
A: There are a couple of sql statements that cannot be executed inside a transaction. User and db space creation are examples of such statements. These are special statements that seldom you will need to synchronize. DbUpdater executes first these statements and then starts a transaction for all the other sql statements. As a consequence, rolling back the transaction will leave these entities changed.

Q: Can I save the result of Database Comparison?
A: The result of Database Comparison (CheckDb) is an XML file containing the list of sql statements required to synchronize the database. You can save it before to call the Update routine. We are working on a more complete reporting file. It will be released in future DbUpdater versions.

Q: How do I change the Producer schema directory that DbUpdater uses?
A: Simply change the "DirSchema" property. This is also included in the project settings.

Q: How can I hide the Console and Progress Info Windows during the Comparer phase?
A: By default, during compare and update execution, DbUpdater shows two windows that inform the user of the operations in progress. A special setting allows to tell to the component which window to show. To hide both the windows, set the property

ProgressInfoKind := pikSilent.

Other settings are available. For example, if you want to show only the Console Window, set the property to "pikConsole".

Q: Is it possible to localize the console messages?
A: Yes. Console window is a class. You can redefine all messages. Moreover, we are studying the possibility to define a custom window to use instead of the standard one. Actually, is already possible by defining a subclass of the "TConsoleFrm". But, at the moment, to do this you need the DbUpdater version with source code.

Q: Is it possible to localize the progress window messages?
A: Yes, it is the same for console messages. You can redefine all messages. Moreover, we are studying the possibility to define a custom window to use instead of the standard one. Actually, is already possible by defining a subclass of the "TProgressInfoFrm". But, at the moment, to do this you need the DbUpdater version with source code.

Q: Does DbUpdater work with Microsoft SQL Server 7/Oracle?
A: No. Current DbUpdater release 2 works with

•  Microsoft SQL Server 2000 or higher

•  Sybase Adaptive Server AnyWhere (ASA) 8 or higher

•  Access 2000 or higher

Q: I use SQL Server 2000 as developer. One of my client uses Sybase Adaptive Server Anywhere (ASA). May I use DbUpdater to Synchronize it?
A: Sure, this is the unique feature of DbUpdater. No matter what provider your customers use, DbUpdater is able to synchronize their database. The DbUpdater release 2 handles Sql Server 2000 and ASA 8 or up. We are working on Access 2000 provider that will be available in DbUpdater 2.2. We plan also to implement in the future Oracle, Interbase and MySql.

Of course, you have to pay a little attention in designing database. For example, if you are using SQL Server and want to allow your customer to use other database, don't use special field properties like identity seed and identity increment, because not all the other database allows to define an identity seed. Conversely, Sql Server don't allows to define more than one identity field for table, whilst in ASA you can.

Finally, DbUpdater release 2 don't parse stored procedures. For release 3, we plan to insert a meta-language for stored procedures and specific parser so that we can translate stored procedures from one provider to the other. But, until that, if you forecast to move from one provider to another, don't use stored procedures!!!

Q: Can DbUpdater copes with very large databases?
A: Yes. The DbUpdater Technology is based on XML schema extraction. There is no limitation in database size. Data content does not affect Database Comparison. Of course, database with thousands of entities defined (tables, fields, indexes, .) will determine a slower database comparison, because the component has to verify more entities.

The Database Update phase will only be affected by the percentage of differences between the two databases.

Q: What happen if I insert a primary key or a unique key and there are conflicting record in the custom database?
A: This is one of the most complex situation. By default, the component contains a general mechanism that avoid to get an error. If you want a complete explanation of this feature, please refer to the full DbUpdater manual. Shortly, the component:

•  Select all conflicting records.

•  repeat step 3 to 10 for each group of conflicting record extracted in step 1)

•  save the first one (say "goodRecord") and put the other in a list of record to be deleted ("lstDelete")

•  Get all foreign keys which points to the current table

•  repeat step 6 to 9 for each child table of step 4)

•  Extract all the records that refers to records in "lstDelete"

•  for each record in 6), change data so that it points to "goodRecord"

•  Copy all record from the "lstDelete" to a temporary table

•  Save "lstDelete" to a temporary table

•  delete all record of the "lstDelete"

•  Add the primary key / unique index

•  Execute an event "AfterCreatePrimaryKey" in which is possible to handle the deleted records

Q: What happen if I insert a foreign key and there are conflicting record in the custom database?
A: This situation resemble the one in which we have to insert a primary key or an unique index, because all the conflicting record has to be deleted. By default, the component contains a general mechanism that avoid to get an error. If you want a complete explanation of this feature, please refer to the full DbUpdater manual. Shortly, the component:

•  Select all records that will not have a corresponding record in the master table, according to the foreign key that has to be created.

•  save these records in a temporary table

•  delete them

•  Add the foreign key

•  execute an event "AfterCreateForeignKey" in which is possible to handle the deleted records

Q: During Updating phase I got errors. What can I do?
A: The Database synchronization is one of that tasks in which you never know the state of the target database. This means that sometimes a special case is encountered (less than 1% of cases) not yet correctly handled. DbUpdater manages sql statement errors in three different mode:

•  stop update

•  skip error statements

•  enqueue at the end of the statement list.

The latter will cover all the situation in which a specific synchronization statement has to be executed "after" some other sql statement. In this situation, checks the error list and verify if they are auto-recovered. If so, the synchronization has been complete successfully.

If you still have some special cases in which DbUpdater does not work, please let us know .

Q: May I need to install something in the client machine?
A: Normally not. DbUpdater is based on the ADO technology and requires the latest Microsoft MDAC version. If the client machine does not have any MDAC installed it is required to install it. Click here to download the latest MDAC version.