Write Conflict Error Only on Server

[dgunner71]

I have 2 odd issues occurring on a server.

First - I'm getting a query write conflict error (image attached). This error is not occurring on any other computer but when I test on the deployment server I get the error. I've tried to replace the front end and the back end with new versions of the software (versions that are working fine when deployed on another computer).
[IMGNOTHUMB]http://bytes.com/attachments/attachment/7419d1389061067/write-conflict.png[/IMGNOTHUMB]

The server has Access 2010 installed. (MS Server 2008r2)

I've tested this problem on computers running 2010 and 2007 (both with Windows 7) - the problems do not occur on these computers. It seems to be a problem with this installation.

As always, any assistance is appreciated.

Gunner

[NeoPa]

This error generally indicates that two separate users (or, more technically, processes) have flagged that same part of the database for update work.

Your configuration settings control how the process should handle conflicts, as well as how much of the database is considered to be the relevant part.

I suspect the difference is probably more with how Access has been configured (Options etc) than which OS it's running on. Including the OS is definitely the right way to ask the question, of course. I just don't think it'll turn out to be the issue on this one. I'd compare all your different options between the machines that work and those that don't and see what's different.

[dgunner71]

Thanks for your reply, NeoPa.

I have some more information that may shed some light on this issue.

The problem began on my latest update which incorporated a new field from a separate table. I currently have my form's record source bound to an SQL statement (entered directly into the record source - that is to say, not a query).

Prior to the update, the record source SQL was just a single table. After my most recent update, I needed to bring a new field in from another table for the filter. When I bring this second field in, I am getting the Write Conflict (still just on the server - all other computers work fine). I would like to correct this issue to work on the server if possible. I've included the before and after SQL statements below; not sure if this will help at all.

Original SQL Record Source statement - work fine:

SELECT tblInventoryTransactions.*
FROM tblInventoryTransactions;

New SQL Record Source statement - raises write conflict:

SELECT tblInventoryTransactions.*
   , tblInventory.txtItemType
FROM tblInventoryTransactions 
   INNER JOIN tblInventory 
      ON tblInventoryTransactions.numTransactionItemID 
         = tblInventory.AID;

As you can see the new statement is not overly complex - it only adds [txtItemType].

As always, your help is greatly appreciated.

Kind regards.

Gunner

[Seth Schrock]

Is there a field in any of the involved tables that has a bit type? If so, you must have it set to not allow null values. If you do, it will let you enter the record the first time fine, but then it won't ever let you edit that record if you left that field null. What I do is to set my checkboxes to have a default value of False so that all new records pass a false value (unless I change it to True) and then my issue goes away.

[zmbd]

This is valid for SQL-Server/MySQL.
This does not hold true if the backend is an Access file.

I'm haveing issues trying to understand why you are using a server as as workstation, that is NOT what it is designed for... I suspect that the server is creating a multiple instance of the files when you attempt to run Access from the zero-hundred terminal on the datafile.

[dgunner71]

zmbd -

I have both the back end and the front end on the server. Users log in via remote desktop (scattered across 3 countries).

Gunner

[dgunner71]

Seth -

I'm sure I do have Yes/No fields in my tables - I'll ensure that I have a default value set for all these and I'll let you know if this changes anything.

For the time being, I've created a work around that may actually work out better. In any event, I would like to understand why this is happening.

Thanks.

Gunner

[Rabbit]

Undo your change and see if that really is the cause.

[Seth Schrock]

If the bit fields are the problem, all you have to do is make sure that you have passes either a true or a false value to it. From what I have read, it is a good practice to make it so that the field cannot be null, as it forces you to pass it a value and then you never forget to do so.

I do know that that is the error message that you receive when this is the problem. However, I'm sure that this isn't the only issue that would cause the message.

[NeoPa]

Have you looked at the options for Access and the VBAIDE (Code Window)? This is where I still expect you to find answers.

[dgunner71]

All -

I found the problem - there was a piece of code that was attempting to update the tblInventory table (the same table that I added to the SQL statement / Record Source). I'm not sure why my other laptops let this query run without the write conflict, but this was indeed the problem.

I over looked the DoCmd.RunSQL statement and the fact that I was only having the problem on the server (which historically has presented some odd issues) I just wasn't looking in this area.

Thanks to everyone for your help - this site is the best site on the internet by and by!

Gunner