Some table attributes cannot simply be transferred from a Microsoft Access table to an ADABAS table.
Case-Sensitive Treatment of Identifiers: Unlike Microsoft Access and the Jet Engine, ADABAS always distinguishes between uppercase and lowercase letters in the identifiers for database names, table names, column names, index names, etc. This poses no problem as long as you access ADABAS tables by means of the "aliasing queries" created by the Upsizing Wizard. And this is definitely an option, since it has no adverse effect on performance. However, if you wish to access the attached tables directly you must, for example, use the column names just as they are displayed in the Access Table Window- Design View or in the relevant window of the ADABAS tool Domain.
Permissions: Permissions that you have assigned within Microsoft Access must first be transferred to the ADABAS database so that accesses there will be subjected to these rules. Following migration, the ADABAS user that you specified when connecting to the database is the owner of the exported tables and, thus, has all permissions.
If you are connected as this user, you can grant privileges to other users for specific tables. For more information, see Section 6.12, "authorization, <grant statement>" in the ADABAS Reference manual.
Counter Fields: After the table has been transferred to an ADABAS server database, counter or autovalue columns are not automatically initialized with a unique value when a new data row is created. The columns in a newly created data row are initialized in ADABAS by means of an insert trigger.
An insert trigger is a short program that the server database executes when creating a data row. The trigger procedure is created by the user after upsizing since it cannot be inserted automatically. For more information on this procedure, see the ADABAS manual AdaBasic.
Validation Text: After the table has been transferred to a server database, if you have entered validation texts, these texts will not be output automatically when the validation rules are violated. Instead, less specific messages are output.
Cascade Update-Related Fields: If you selected Cascade Update-Related Fields under the Relationships option as a rule for referential integrity in Microsoft Access, this attribute is not automatically emulated in the server database. The cascading of update-related fields is implemented in ADABAS by means of an update trigger (see above: Counter Fields).
Default Values: Default values and values that are inserted in a new data row by means of an insert trigger are not visible when first created and do not become visible until the data row is reselected. The data row is automatically reselected if it was created with a column containing a value that is unique within the table and that was used for recreating the application program.
Performance: If performance does not meet your expectations after upsizing; i.e., the application functions but requires too much time for simple procedures, check the application for the following characteristics and modify the application if any of these characteristics apply:
· The application updates or examines the data rows in a loop in that it issues an SQL statement at each loop pass. Remedy: If the application uses a "recordset.findfirst" statement in the loop, find out how you can select the record set in one step in the correct order, for example by inserting an appropriate ORDER BY clause in the SELECT statement. If this is not possible or also takes too much time, set an index to the necessary sequence criterion.
· In an SQL statement, the application applies a function to a large number of data rows that ADABAS cannot execute because ADABAS either does not know this function or does not know it under this name. Although this does not result in an error, each field to be updated is transferred to the client via the network, manipulated locally by the function and returned to the database. Remedy: Refer to the ADABAS Reference manual to find the name of the function in ADABAS.
·
· The application accesses both local tables and tables located in the server database within the same SQL statement. Such a statement cannot be processed by the server database alone nor can it be processed exclusively on the local level. The Jet Engine suitably resolves this statement and, after transferring the necessary data from the server database to the workstation, executes it. If the result of the statement is an updating of the data in the server database, following the update procedure the data is transferred from the workstation back to the server database. Depending on the size of the transfer, this procedure may take the form of noticeably poor performance. Remedy: Reduce the frequency of comparisons between local tables and tables in the server database. As far as possible, formulate SQL comparison statements so that the resulting data flow between the workstation and server database clearly emerges from it. Do not blindly trust the Jet Engine to discover the best strategy for you. Transfer only what is necessary, i.e. the updated data between the local tables and the tables in the server database.