Release Notes

You need a Java enabled browser!

This is the currently shipping README.1ST file.

ConnectEase Version 1.14 Release Notes - 09/15/98
Installing the software:

THIS VERSION IS FOR 32-BIT WINDOWS 95/98/NT ENVIRONMENTS ONLY. THIS VERSION HAS NOT BEEN TESTED WITH ANY OTHER OPERATING SYSTEM.

Download the ZIP file and extract to a temporary directory or diskette. Run SETUP and follow the instructions. The complete reference manual for
ConnectEase may be viewed on-line at http://www.connectease.com.

If you already have a working copy of ConnectEase 1.11 or higher, you can simply download and install the 1.14 update file which contains a new
DE453_32.DLL which must replace your old DE453_32.DLL (located in your \WINDOWS\SYSTEM directory, \WINNT\SYSTEM32 for NT Users).

DISCLAIMER

LANimation Consulting Corporation (LCC). disclaims liability for damages from your use of this software other than the purchase price of the software license. LCC recommends that any user of this software product take appropriate precautionary steps to protect against the loss of critical data and information systems that might be damaged in the event of a malfunction of this or any other software by making frequent backup copies of data and information systems and that could be affected by failure of software.

Specifications and prices subject to change without notice. This software provided 'AS-IS' with no warranty of any kind.

Problems Corrected & Added Enhancements

2-byte integer (<5 digits) fields containing negative numbers would cause an 'Out of Range' error
when accessing data from the table. Corrected.
*

A checkbox has been added to the 'Options' page of the datasource setup dialog box labeled 'Require Exception Acknowledgement?'. Checking this box cause the driver to display a message with an 'Ok' button each time the driver encounters an exception, which can be useful for troubleshooting. For normal driver operation, leave this option unchecked. Exceptions will be returned to the calling application as ODBC call failures, in either case.

In 1.10, if a table had no unique fields defined for a form, inserts would fail with 'Attempt to insert record with duplicate key'. Fixed.

Support for filtered table names has been added. (and FIXED 1.13) This means you can apply the same character substitution rules to table names that you could apply for previously with field names. A checkbox has been added to 'Options' to allow you to choose to enable or disable this feature.

CAUTION: You must insure that the application of the substitution filter does not create ambiguities in the ODBC connection. For example, say you have created a filter which substitutes an underscore ('_') for a period ('.') in field and/or table names. If you have an object named 'Account.Balance' in your database, the driver will change this name to
'Account_Balance'. If you already have ANOTHER object named 'Account_Balance' defined, very strange things are bound to happen!

Also, the way table re-naming works internally when a table is opened is that the driver first attempts to find the named table without applying the filter. If that succeeds, then the function is successful. It only applies the filter if the attempt to locate the table with
the unfiltered name fails. The reason we use this technique is that the driver depends on
itself when calculating relational formulas, which refer to fields and tables by their native
names, not filtered names. We are providing this for your information.
*

Problem: Access reports 'Cannot find object named 'xxxx'....' when trying to link/import a DataEase form. Other front ends would also fail to open the table.

Cause: The form was created with a version of DataEase prior to 4.x and has not been modified since (even though the database has been upgraded). The driver fails to recognize certain properties of such tables and will not open them properly.

Solution: Modify the form definition (adding or deleting a character from the screen definition will do) in 4.53 and save the form. This will update the format of the definition so that ConnectEase will open it.

This version has been tested with Microsoft Access 97 for date field compliance as far as Y2K, using dates as sort keys and searching for date values. ConnectEase follows DataEase base year calculation.

All sorts are alphabetic (case-insensitive).

Corrected occasional problem when running ODBC 3.01 setup in which an 'invalid page fault in KERNEL.EXE' would occur in RUNDLL32.EXE upon exit from the ODBC Administrator.

Similar to above, when user was asked for a User Name and Password by the driver when connecting to the data source. If the user canceled without properly logging in, an exception would sometimes occur. This has been reworked.

When a 'Waiting For Lock' message window was displayed, pressing 'Cancel' had no effect. Now, pressing Cancel will cause a 'lock failed' exception to be generated.

Numeric string field types are now left-padded by the driver with '0' characters before being written to records.

In tables that had numeric or choice fields as a component of uniqueness, records would show up in a Microsoft Access datasheet as #deleted. Access 97 passes criteria in for numeric fields as a SQL_C_DOUBLE, which requires conversion to the native DE field type before using as a comparison criteria. Fixed.

*
Handling of Prevent Entry and Virtual fields has been enhanced as follows:

An 'Enforce Prevent Entry' checkbox has been added to the Options page of the datasource setup dialog.

When Enforce Prevent Entry is checked, attempting to write data to a field that is flagged prevent entry or virtual will raise an exception.

When not checked, writing to prevent entry fields is permitted and attempts to write to virtual fields are ignored silently.

Support for 'Sequence From' derivation formulas has been added WITH THE FOLLOWING LIMITATIONS:

A check box has been supplied on the 'Options' tab datasource setup dialog to control whether you want the driver to derive 'Sequence from' fields for you. By default 'Sequence from' processing is NOT enabled.

ConnectEase will ONLY calculate sequence from values if the field to be calculated is indexed.

The Sequence From value is calculated just prior to a record being written to the table that has a blank value in the sequence from field. Unlike native DataEase, this means that it is not possible to display the value until after the record has been saved. But it also means that the chance of duplicate values occuring in multiuser installations is greatly minimized. (We recommend that you forego 'sequence from' derivations in favor of a using a unique value generator. This is the only way to guarantee uniqueness.)

The parser is very limited. Make sure that your 'Sequence from' derivation is described on the first line of the formula definition text box and that there is no other text in the formula other than Sequence from <base value>

Do not append comments, etc to the formula text.

General Discussion

When entering data from Access into a table which uses a derived value (like a sequence from) as a primary key value, Access will report #deleted after the record has been entered. This is because Access sent the record to the driver with a blank value in the primary key, the driver then calculates and places a non-blank value in the field. After returning from the insert record transaction, Access requeries the driver using what it 'thinks' the primary key is (Blank), and gets no results. So Access believes the record was deleted by another user. However, if the data set is refreshed (Shift-F9 when in data sheet view), the new record is displayed correctly. This section from a Microsoft publication on the Jet database engine (Jet is the middleware between Access and VB/DAO and database servers) describes the issue:

" Volatile Primary Keys

"If another user changes a bookmark column of a row, Jet loses its handle to the record and considers it to be deleted. (Re-executing the query will remedy this situation, provided the record still meets the query's criteria.) If a trigger on the server changes the key values at the time of an update, Jet might successfully update the row, but Microsoft
Access will immediately display it as "#Deleted."

However, if a trigger on the server changes or initializes the key values at the time of an insert (for example, a trigger that simulates a "Counter" [ed: like 'Sequence from' can] column or a column in a Microsoft SQL Server 6.0 database with the IDENTITY attribute set), Jet notices that the key has changed, and re-selects the new row, based on all other values in the new record. Provided that this re-select returns exactly one row, Jet will acquire the key values and be able to keep track of the new record. If zero rows or more than one row is returned by this re-selection, the row appears as "#Deleted"."

One possible solution to this would be to add an extra field to the DataEase form whose value is always calculated by the Access or VB front-end (perhaps the current date/time) and is always written before a record is saved inserts and updates by the front-end application. That way it is likely that jet will be able to find the record based on the other contents as described above.

Note you will not be able to calculate the value in Access in datasheet or non-form-based views of the data. But most turnkey applications use forms for user access, so you can calculate the value of the control linked to this extra field in response to the Before Insert and Before Update events prior to saving the record.

There is also some discussion of synching Access with a database server in the Microsoft book "Building Applications with Microsoft® Access for Windows® 95".

Q: I linked my DataEase tables into Access 97, but I left the 'Save Password' checkbox empty so that the driver would prompt the user each time the table was opened for a valid user name and password. If the table is the first one opened, it asks the user to log in, as it should. But, if the user cancels from the login dialog, it opens the table ANYWAY. How do I keep this from happening? Also, it only as for the login name on the first table opened. All of the other tables until I log out of Access can be opened and closed without any more prompts. Why?

A: Two things are at work here. First, when you set up the ODBC datasource to your database, I'll bet you provided a valid user ID and password in the setup dialog. Then you linked the table to Access, believing that if you left the 'Save Password' check box unchecked that the driver would authenticate the user, which it does. But, the way Access works, if the manual login fails for whatever reason, it falls back to checking to see if a user id and password is set for the data source. If so, it then uses that to open the connection to the table.

The answer to part one is to leave the user name and password blank in the data source setup dialog if you want to force authentication of the user each time a connection is opened. Or, you can follow Microsoft's advice: "JetTryAuth- If your application doesn't use Microsoft Access security, set the JetTryAuth (Found in Microsoft\Access\7.0\Jet\3.0\Engines\ODBC folder of the Windows Registry)option to 0 to prevent Microsoft Access from attempting to log on to the server using the active user name and password. On some servers, a failed logon can take time and slow down the server."

The reason it only authenticates the user once is that Access opens a connection to an ODBC data source once and then uses it for the duration of the Access session. So once you successfully open any linked table, you have opened the connection Access will use for the duration of the session. The only way to close the connection is to close Access. Again much of this information is covered the 'Client-Server section' in the Microsoft book, which ships with Access: "Building Applications with Microsoft® Access for Windows® 95"

 IMPORTANT NOTE: If you modify a form definition in DataEase that you have attached or linked to
 a front-end, you MUST delete and re-link the form before using it through the front end again.
 For example, if you have a form linked into Access97 and you add a field to the form definition
 using DataEase, Access97 will not know about the change until you delete and re-establish
 the link to the form.

Helpful MS-Access 97 registry options that can aid in troubleshooting ODBC issues:

System Registry Settings

When using Jet 2.0 and Microsoft Access 2.0, configuration settings were stored in an
INI file called, MSACC20.INI. When using Jet 3.0 or 3.5 and Microsoft Access 7.0 (or
any other 32-bit client of Jet’s), configuration settings are stored in the system registry.
The following entries affect Jet's use of ODBC and server data. All reside in the under the
registry key \\HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\3.0\Engines\ODBC. (or 3.5, as the
case may be).

Note  This registry location may vary based on the calling application, i.e., Access, VB,
a custom app, etc.

Key	Type	Default	Description
LoginTimeout	DWORD	20	Number of seconds to wait for a login attempt to succeed.
QueryTimeout	DWORD	60	Number of seconds to wait for a query to execute before failing.
ConnectionTimeout	DWORD	600	Number of seconds to wait before closing an idle connection.
AsyncRetryInterval	DWORD	500	Number of milliseconds to wait between retries on an asynchronous connection.
AttachCaseSensitive	DWORD		If False(0), will link to the first name matching the specified string in a match that isn’t case-sensitive. If True(1), requires a case-sensitive match of the name.
AttachableObjects	SZ	TABLE	The list of objects that Microsoft Jet will allow links to (TABLE, NEW,SYSTEMTABLE, ALIAS, SYNONYM). Values are of type REG_SZ.
SnapshotOnly	DWORD	0	If False(0), you will get index information on linked tables to allow dynasets if possible. If True(1), Microsoft Jet will ignore index information and thereby force snapshots on all linked tables.
TraceSQLMode	DWORD	0	Initiates sending a trace of SQL statements sent to an ODBC data source to the file SQLOUT.TXT. Values are 0 (No) and 1 (Yes). The default is 0 (values are of type REG_DWORD). This entry is interchangeable with SQLTracemode.
TraceODBCAPI	DWORD	0	Initiates sending a trace of ODBC API calls to the file ODBCAPI.TXT. Values are 0 (No) and 1 (Yes). The default is 0 (values are of type REG_DWORD).
DisableAsync	DWORD	1	Forces synchronous query execution. Values are 0 (use asynchronous query execution if possible) and 1 (force synchronous query execution). The default is 0 (values are of type REG_DWORD).
JetTryAuth	DWORD	1	Uses the Microsoft Access user name and password to log on to the server before prompting. Values are 0 (No) and 1 (Yes). The default is 0 (values are of type REG_DWORD).
PreparedInsert	DWORD	0	Uses a prepared INSERT statement that inserts data in all columns. Values are 0 (use a custom INSERT statement that inserts only non-Null values) and 1 (use a prepared INSERT statement). The default is 0 (values are of type REG_DWORD).Using prepared INSERT statements can cause Nulls to overwrite server defaults and can cause triggers to execute on columns that weren’t inserted explicitly.
PreparedUpdate	DWORD	0	Uses a prepared UPDATE statement that updates data in all columns. Values are 0 (use a custom UPDATE statement that sets only columns that have changed) and 1 (use a prepared UPDATE statement). The default is 0(values are of type REG_DWORD).Using prepared UPDATE statements can cause triggers to execute on columns that weren’t changed explicitly.
FastRequery	DWORD	0	Uses a prepared SELECT statement for parameterized queries. Values are 0 (No) and 1 (Yes). The default is 0 (values are of type REG_DWORD).