First, my sympathies to anyone who still has to deal with Paradox databases. I recently setup Microsoft Access 2007 on a Windows 7 64-bit computer to manipulate data in an old Boreland Paradox database (from a limited user account). I consider this to be the computer equivalent of putting the engine from an old VW Beetle into a new Porche 914 (rather than the other way around)... but nonetheless, it has been done. The only serious problem was the following error message, which appeared upon opening the database from Access:

The cause was a series of permissions errors caused by the more strict access controls in Windows Vista/7. To fix the error perform the following steps:

1. Grant write permissions for the user/group who will be running Access on HKEY_LOCAL_MACHINE\SOFTWARE[\Wow6432Node]\Borland\Database Engine\Settings in the Windows Registry.
2. Change the BDE configuration to avoid writing to C:\PDOXUSRS.NET
   1. Run "C:\Program Files (x86)\Common Files\Borland Shared\Bde\BDEADMIN.exe" as an Administrator
   2. Navigate to Configuration | Drivers | Native | Paradox
   3. Change the NET DIR parameter to somewhere writable (and shared between users). I created a folder in %systemdrive%\ProgramData.
3. If necessary, grant write permissions on HKEY_CLASSES_ROOT\.html in the Widnows Registry. I don't believe this was strictly required, but at one point I had enabled it during testing and am not completely certain if it was ruled out as a cause of the problem.

After performing the above steps, the error should be resolved. If not, I suggest using Process Monitor to look for permissions errors and attempt to resolve them (which is what I did). Best of luck.

Additional Information: Also, for those looking to the future, Access 2010 and later have dropped support Paradox 3-7, so further workarounds may be required.

Access has 2 distinct notions of an index on a linked table/view. The first is a "true" index, which resides in the linked database and is not used/modified directly by Jet/Access. These "true" indexes can be used by the database engine for executing query plans and are enforced during data modification (e.g. for uniqueness). The second is a "pseudo-index" which is "a dynamic cross-reference" that Jet/Access creates/maintains to facilitate data modification on linked tables/views which lack a unique index in the linked database. Constraints in pseudo-indexes can not be enforced outside of Access (and I am unsure if they are even enforced within Access) and are not used during query execution on the linked database (of course, although I have no knowledge of how they are used within Access...).

How to add indexes to linked tables/views

Create the indexes in the linked database (e.g. SQL Server) and refresh the table/view link (using Linked Table Manager or programmatically with TableDef.RefreshLink).

How to add pseudo-indexes to linked tables/views

When a link to a table/view without an index is created, Access prompts the user with a "Select Unique Record Identifier" dialog box (which is also triggered from code using DoCmd.TransferDatabase to create the link). Simply select the fields to be included in the index. Note that when creating the table using DAO/ADOX methods, this dialog is not presented and the pseudo-index is not created. Also, attempting to add an index to a linked table using DAO/ADOX results in an error (similarly to attempting to add an index through the table designer). To create the pseudo-index programmatically use Database.Execute to run a CREATE INDEX statement on the linked table/view. Jet will decide that the index must be a pseudo-index and create one.

Why pseudo-indexes?

There are several situations where an index in the linked database is not desirable. Particularly on updateable views where the underlying table(s) are updated frequently. Creating an indexed view has the side effect of materializing the table on disk, which requires every update to the underlying tables to involve multiple writes to disk as both the original table and the indexed view are updated. Yet, without a pseudo-index, the view would not be updateable from Access. So in these situations a pseudo-index is required.

Caveats

Unfortunately, pseudo-indexes are not preserved when the linked table connection is updated. So for any scripts which modify the connection (e.g. to re-point a table to a different server) must recreate the indexes after refreshing the link. The following code is a general outline for what is required (note that index direction is not currently preserved). The code should be run on the index before the connection is updated, then the returned SQL run after the connection is changed and the link is refreshed:

For anyone who has tried creating a blank Access Data Page in Access 2003 (or Access 2002 aka Access XP) on Windows Vista or 7, you will have seen the following message:

But what does it mean and how do we deal with it? The cause is explained in Microsoft KB896865, but the solution that it provides is insufficient (since Triedit.dll is not present on Vista and 7). The solution for these operating systems is to install the DHTML Editing Control for Applications Redistributable Package (x86), which will install triedit.dll to C:\Program Files\Common Files\microsoft shared\DhtmlEd and register the DLL.

Just a quick warning: Don't install Access Runtime 2010 on any computer where you are still using Access 2003 (this may apply to other version combinations as well). I recently installed the latest version of SQL Server Migration Assistant for Access, which requires the Microsoft Access 2010 Runtime. After installing the runtime, creating an event procedure would cause Access 2003 to crash. With a bit more testing, I found that the Visual Basic Editor was automatically creating a reference to the "Microsoft Access 14.0 Object Library" (that came with the 2010 Runtime) instead of the "Microsoft Access 11.0 Object Library" (that came with Access 2003) and it would not allow me to change this library. After removing the 2010 runtime, all is back to normal.

I recently encountered the following error in Microsoft Access 2000:

Apparently this is a catch-all error for any condition where the database engine (or presumably one thread of the engine) is busy completing a task and something else (such as a VBA macro) attempts to perform a function which requires the engine to perform some task. It is horribly difficult to track down, due to the lack of internal debugging interfaces in Access, but check for macros which may be updating visual elements in a form and getting into a loop (for example, OnCurrent actions cascading in a loop or likewise). In my particular case, the error was only triggered when a filter was applied in a form which contained a subform with a field whose default value depended on a field in the parent form. Once I removed the default value from the field in the subform, the error disappeared. (Note also that this only occurred in Access 2000, not Access 2003)

Good luck in tracking down the source of this error if you encounter it.

I recently encountered the following message in Microsoft Access 2003 when attempting to update any column of a linked table (linked to an MSSQL2005 DB): The interesting part of this story is that there really shouldn't be a write conflict in the data because the linked table in question is in a DB on my local computer which is only being accessed by Access and has no triggers which could be confusing Access. Further investigation, and a useful thread on Bytes, revealed that the problem was columns in the linked table which have the datatype BIT and was allowed to be NULL. Changing the columns to BIT NOT NULL and refreshing the linked table in Access solved the problem.

Update: KB 280730 covers this issue.

I recently encountered the following error message in Microsoft Access 2003: After further investigation, as suggested by a thread on microsoft.public.access.forms, the problem appears to be related to duplicate columns in the form Record Source. However, the error is not limited to simple duplicate columns. In my case, the duplicate name was the result of a table join where the compound names were distinct (i.e. Table1.Col1 and Table2.Col1), but the simple column names were not, which resulted in the error. Perhaps I shouldn't be using joined tables as my Record Source... perhaps.