In most cases, you can start up your usual Microsoft Access application immediately after the migration process is completed. Run through the usual tables and queries in order to determine whether the existing functionality was retained beyond the migration process.
Updating ported tables
You should now check whether Microsoft Access allows the ported tables to be updated. If not, you should make sure that a unique index to the tables to be updated has been defined.
A table attached to Microsoft Access can be updated only if it has a unique index. Although the Upsizing Wizard ports an existing unique index, it does not generate an index to the exported table if none was defined.
You can define a unique index using, for example, ADABAS Domain. However, you can also issue a CREATE UNIQUE INDEX statement from Microsoft Access by means of an SQL Pass-Through Query.
For more information, see Section 5.23, "data definition, <create index statement>" in the ADABAS Reference manual.
Case-sensitive Text Comparison
If you perform queries whose WHERE condition is based on text comparison or issue "recordset.findfirst" statements that access a text field and you discover that data rows are no longer found that were found before migration, the problem may be related to the handling of uppercase and lowercase letters when the ADABAS database performs a text comparison. The default method used for text comparison in a Microsoft Access database is not case-sensitive in contrast to an ADABAS database.
To prevent ADABAS from distinguishing between uppercase and lowercase letters, in the SQL statement, simply base the comparison on the result of the UCASE function, applied to the column contents, instead of basing it on the column contents.
Example:
If the SQL statement was:
SELECT Cust_no FROM Customer
WHERE Cust_name="miller"
and it also returned the customer number of the customer "miller", the following minor modification must be made following migration:
SELECT Cust_no FROM Customer
WHERE UCASE(Cust_name)=MILLER"
The UCASE function instructs the ADABAS server database to convert the contents of each cell in this column to uppercase letters before performing the comparison; i.e., it now follows the same procedure that was formerly executed automatically by Microsoft Access without your intervention. Naturally, the other value in the comparison must also be written in uppercase letters. This can be achieved, for example, by again inserting the UCASE function before the other column name as well (if the application is comparing two columns) or by changing this value to uppercase letters beforehand (if a fixed value is being compared).
If you originally generated the query in the Microsoft Access Select Query window as in this example, you can also easily modify it there:
As in this example, you can prevent the column contents from being output in uppercase letters and reinsert the column in the query as it was originally written.
You also have the option of using an ADABAS extension of the LIKE predicate, which is somewhat more efficient than the method described above. Using a "match element", you can specify a number of characters that are to be handled identically for each character position, e.g.:
SELECT * FROM Customer WHERE Cust_name LIKE '(mM)(iI)(lL)(lL)(eE)(rR)'
For more information on this variant, see the description of the LIKE predicate in Section 3.13.8, "basic elements, <like predicate>" in the ADABAS Reference manual.
Unsatisfactory Performance
If you find that upsizing was successful but performance did not improve as you had expected, look for the possible causes as follows:
· Are the application and server database running on the same computer? If yes, you have shown that upsizing was successful but are not yet enjoying the advantages of a client/server architecture because loads are not being distributed to more than one computer. If this is the case, you can expect even worse performance since the computer is additionally loaded down by another program - the server database - running simultaneously. Take the next step as soon as possible and move the server database to another dedicated computer in the network.
· If, despite a distribution in the network, performance is worse (or did not improve as expected), the problem is often related to the way in which the application accesses the database. You can sometimes eliminate this problem by making minor changes to the application. Refer to Section Which Applications Benefit from Upsizing in order to find out why your application is not benefiting.