Is it possible to use Oracle/MySQL/Sybase/my DBMS as Backend in an Access Data Project (ADP)?

No, it isn't! Right now it is simply not possible to use any other DBMS than Microsoft SQL Server and MSDE (Microsoft Data Engine) as Backend for an Access-Data-Project and there is definately no workaround to circumvent this limitation.

Until now there is no official information available that Microsoft plans to support other DBMS as Backends for ADPs in the future. As to integrate support of another DBMS into the ADP-Architecture will incur a major effort, even with updates for new versions of the DBMS, and will highly depend on the features of that DBMS, I think it is extremly unlikely that Microsoft will support any Third-Party-DBMS in ADPs ever.

If you try to open an ADP-File (Access Data Project) in a multiuser environment that is already opened by another you get the message 'The Microsoft Access project 'xyz' will be opened read-only because one of the following occurred:'. What can one do about that?

This is behavior by design. With a MDB-Application all information about which user is editing which object is stored within the .LDB-File. This enables multiple users to open and edit the same MDB-File at the same time. This issue is described in the Microsoft Knowledgebase article 318868.

With an ADP-File there is no LDB-File at all, therefore Access has to assume that the first user that opens an ADP-File is making changes to the object-definitions of forms, report, etc. and locks the whole file. For this reason all subsequent users will only get read-only access to that file. This write-protection only affects objects local to the ADP-File (Forms, Report, etc,) but not the data stored in the SQL-Server-Database.

The simple workaround for this problem is to open Access and the ADP-File in Runtime-Mode. Because it is not possible to make any changes to the object-definition in Runtime-Mode anyway, Access will not issue any warning about the project being opened read-only.

You can apply this workaround by opening the ADP not directly but by using a shortcut which contains the Runtime-Switch in the command line. The command line of such a shortcut should roughly look like this:

"C:\Path\to\MSACCESS.EXE" /runtime "C:\Path\to\YourApplication.adp"

Unfortunately this workaround only does the trick with up to 20 concurrent users of the ADP-File. The 21st user opening the ADP will receive the message "The file is not in the correct format for a Microsoft Access project." and it is not possible to open any further instances of the ADP-App.

A better solution to the whole problem is to put a copy of the ADP-File on each user's own client-computer. Besides solving the original problem this approach has several other advantages. It will result in slight performance benefits, because the Access-Objects (Forms, Reports, etc.) can be loaded from a local file and haven't to be loaded over the network any more. Furthermore this approach will increase stability of the front-end-file because corruption of Access-Files is extremely less likely if only one user works with a file at a time. Even if there is a corruption-issue nevertheless it will not affect all users of the application but only the one whose local copy of the file got corrupted.

To update the local ADP-files with newer versions you can start your application using a script or a small startup-program that copies the new version to the client if required. You can either develop your own solution to this problem or you can use an existing solution like Tony Toews' Auto FE Updater.