1. That setup is a direct violation of your license agreement with Sage

2. Use a common SharedData folder.  

I know that it is a violation of the license agreement. I am suspecting a client of doing this and want to prevent it via the system. I have tried to warn them that data corruption issues can occur but they don't seem to believe. They won't acknowledge that they are doing this. I need to have a way to prove that they are doing this and then stop supporting based on this (or escalate to their management that we will stop support if this scenario exists). My question is how can I prevent this or even detect that this is going on.

Use a common SharedData folder

You cannot prevent a client (or anyone) from being dishonest, there is no setting in Sage 300 that will prevent the client from doing this. Contact Sage directly and discuss the issue with them, I'm sure they have ways and means to persuade the client to change his behaviour.

Just have two people on different servers edit the same GL batch (or AP Invoice, etc.) at the same time.  The first one who posts wins, the second one loses.

1. The other server is setup by some staff at the client. So, I really don't have control of SharedData location on that server.

2. If two users edit the same batch and it causes issues, they can still have users of different modules on each server, e.g. AP users on one server  and AR users on the other.

What I am looking for is a way to prevent such setup from working or to be able to identify that such a scenario exists in order to escalate to their management.

We already told you everything.  You can't prevent it, you can only report it.  

Understood. But to report, I need to be able to show that this is being done with certainty. I am looking for anything specific in the db on behaviour that will confirm this. Officially, no one is telling me that this is being done but some IT staff have hinted that they may do this. If and when they do it, I want to know if there is a way of knowing it for certain.

There is nothing in the database that will show this.  You need to stop playing games with them and lay out the truth.  Or drop them as a client, because this setup _will_ eventually corrupt the database.

To do that, I need proof. Which unfortunately seems is not possible. You cannot tell a client that you are dropping them because of hearsay.

I already told you.  Have two people edit the same batch and save their changes.  Or two people run I/C dayend processing.  Or a bank reconciliation.  Or create a new year in GL.  Or activate a module.  Of course, make a backup before you start.

But why are you arguing with us?  We're not the ones at fault, your client is.

Sorry, if I sounded like arguing. That is not the intention. I do not have access to the other server to conduct the tests that you suggested. My intention is just to verify that the client has not done a second installation and using the same company database from that installation. I have no proof, just hearsay. I cannot hold the client to be at fault based just on this.

Here's my two cents.  (If their management feels that there are no issue and approves this test)  Change the database account passwords in SQL server.  Update database setup in the good environment.  This should break another copy of the site folder since the password will be incorrect.  Either you get calls for support or a new SQL account will "Magically" get created with access to the databases.  Note:  If other apps use this sql server you will have to deal with them first.

Their IT staff maintains the db server. So, password change is under their control.

If you cannot access the SQL server there isn't much you can do.  Your options were the steps above or to access SQL server management studio and review the number of connections to the Accpac databases.  This second option is not very reliable since there could be other connections to the data from third party applications but it might give you some ideas.

Get the users to run the System Diagnostic "a4wdiag" and send you the log file and you'll have all the proof you need.

Write a letter to the business owner, telling him that you  will not be responsible for any corruption in his accounting data, and make him sign it.