The current version of Microsoft Access does not support replicated databases

[kagoodwin13]

Hi all. I am using Microsoft Access 2016 through Office 365. When trying to open a client's database, I get this error:

The current version of Microsoft Access does not support replicated databases.  To use this database, open in a previous version of Microsoft Access.

I tried this: https://support.microsoft.com/en-us/kb/290052
But received the same error.

I tried this: http://extramiledata.com/remove-repl...cess-database/
But received the same error.

I tried this: http://dba.stackexchange.com/questio...-access-is-any
But received the same error.

Is there something I can tell the client to do to make their database more friendly with updated Access? I'm not even sure how a database is replicated to begin with. Even with all my Access experience, I've never come across the need to replicate a database. It seems like a very old function that was solved after Access 2000. Is there a way for them to un-replicate the database first?

[ssanfu]

I'm not even sure how a database is replicated to begin with.

Database replication

Lets set up a scenario:
You are the sales manager of a SnapOn franchise and have 2 salesmen: Sam and Dawn. Sam and Dawn have their distinct sales areas.
You have an unsplit Access 97 database on your computer. Back in the day, there was little or no internet available and no wireless option. But your salespeople need to enter data into the database. What to do?

If each salesperson puts a copy of the database on their laptop, how would the new orders be merged into the master database (on the managers computer) when the salespeople get back at the end of the week?

Microsoft's solution was database replication. Using the master dB, you create 2 replicated dBs that the salespeople use for the week. When the salespeople return at the end of the week, the new orders from the 2 replicated dBs would be merged back to the master database.

Theoretically, this would eliminate conflicts of PK fields.

According to several sites, you would need to use the original master database OR convert a replicated dB to an non-replicated database.

If you only have a replicated dB (master is not available), you would need to use the same version database of the replicated dB to do the conversion. So in the scenario above, you would need to have Access 97.



Your 2nd link describes how to convert a replicated dB to the accdb format.
Here is another http://www.dbforums.com/showthread.p...om-Access-2003

Is there something I can tell the client to do to make their database more friendly with updated Access?

They might have to find an Access developer nearby that can do the conversion..

[CJ_London]

The replicated db will have a number of 'replication columns' in all replicated tables using a replication ID datatype plus a timestamp or two - can't remember offhand.

To dereplicate, you will need to create a new db, then copy all objects across, then delete these replication columns in all the tables. Other thing to note is the PK will be autonumber - random, you get large positive and negative numbers. This should not matter since they just identify the record, but if you wanted to make them incremental, you will have quite a job converting them. Personally I use random quite a bit to discourage those users who have permission to see them from considering them to have any meaning - particularly order of entry.

However you do need to check with your client - they may still be using replication. There are many instances even now when it has it's uses - I support several systems with clients who need it because they are literally in the middle of a field with no internet access, or at a show where internet access is patchy at best - and anyway, access doesn't work well over WAN/VPN - often too slow. I don't use the 2003 access replication method but have developed my own which is more focused on the actual requirements of the application rather than replicating everything.

If they are still using it, then you will need to get yourself a copy of Access 2003 and develop in that.

Doing development work on replicated db's is complicated. You need to ensure all users have synchronised to the master, then they must do nothing in terms of data input/changes until you have had your changes to the master installed, then issue all users with new replicas - their old ones will not synchronise with the new master. You cannot copy a master, the copy will be a replica.

Normally the db would be split and it is only the back end that would be replicated. Front ends would be distributed in the normal way.

[kagoodwin13]

The replicated db will have a number of 'replication columns' in all replicated tables using a replication ID datatype plus a timestamp or two - can't remember offhand.

To dereplicate, you will need to create a new db, then copy all objects across, then delete these replication columns in all the tables. Other thing to note is the PK will be autonumber - random, you get large positive and negative numbers. This should not matter since they just identify the record, but if you wanted to make them incremental, you will have quite a job converting them. Personally I use random quite a bit to discourage those users who have permission to see them from considering them to have any meaning - particularly order of entry.

However you do need to check with your client - they may still be using replication. There are many instances even now when it has it's uses - I support several systems with clients who need it because they are literally in the middle of a field with no internet access, or at a show where internet access is patchy at best - and anyway, access doesn't work well over WAN/VPN - often too slow. I don't use the 2003 access replication method but have developed my own which is more focused on the actual requirements of the application rather than replicating everything.

If they are still using it, then you will need to get yourself a copy of Access 2003 and develop in that.

Doing development work on replicated db's is complicated. You need to ensure all users have synchronised to the master, then they must do nothing in terms of data input/changes until you have had your changes to the master installed, then issue all users with new replicas - their old ones will not synchronise with the new master. You cannot copy a master, the copy will be a replica.

Normally the db would be split and it is only the back end that would be replicated. Front ends would be distributed in the normal way.

Thanks for your in depth answer. I will decline this job based on the complications from replicated databases. Even if I were to make the requested changes, the front-end would have to be distributed to all users to take effect. Since I am not at the client location, this would prove to be too complicated to do remotely.

My solution for this in the past was just to use a front-end and require VPN to a shared drive back-end. (More specifically, the "front-end" was a batch command to download the master front-end from the shared drive, to the local drive, then open.) Even though performance was slow, it was the only way I saw to prevent primary key violations. Basically, I told the users, "deal with it."

I worked for another company that tried to do replication via an "offline sync" functionality. There were tens of thousands of hours in development spent only to call the project a failure.