I have a mySQL database that tracks our projects and drives our website's display of their info. For ease of updating the database I have set up an access database that used an ODBC connection (MySQL ODBC 5.1) to edit the data. It has been working just fine for the past few months with no hiccups.
However, last night users(2 of 3) experienced Write Conflict errors. The users could only Copy the changes to the Clipboard or Drop the changes. So thinking there is something wrong with the Access database I created a new access database, linked the tables through the ODBC connection, and still the issue occurred. I also deleted and recreated the ODBC connection, to no effect.
So where do I go from here? What could have caused this issue to crop up now, not when I was setting this up months ago?
There have been no changes to the database server, database or access database in the last week (+5 days).
We have made sure that only one instance of Access is attempting to effect the database.
All tables have a PK and a timestamp column.
We are not using any forms, just using the Table interface.
The server has not been updated, nor has the ODBC connection.
We are using Access 2007
Nothing is showing up in the server's error log when we try and update rows.
In general, all ODBC databases used from Access need to have PKs in all tables and timestamp fields in them that are updated each time the record is changed. Access uses this in bound forms for handling refreshes of the bound data and Jet uses them in in choosing how to tell the ODBC database what do update.
You may be able to get things to work with some tables without PK and timestamp, but I've found that it's best just to make sure that all your tables have them so you don't run into the problem (I never have any tables with no PK, of course).y
Make sure BIT columns have default values that are not NULL. Any records which have a BIT column set to NULL could get the Write Conflict error.
Related
I have this problem: I'm using a SQL Server 2008R2 backend and MS Access 2000 frontend where some tables are connected via ODBC.
Following Structure (Tables all on SQL-Server):
Import (not connected to Access)
Products (connected via ODBC to Access)
Pricing (connected via ODBC to Access)
I want to fill the Pricing table automatically with some data from Products and Import. This is supposed to run as a SQL Agent job with a T-SQL script.
I want to insert the data from "Products" with following command:
INSERT INTO Pricing (Productnr, Manufacturernr)
(SELECT Productnr, Manufacturernr
FROM Products
WHERE Valid = 1
AND Productnr NOT IN (SELECT Productnr FROM Pricing ));
Right after that the inserted rows are locked for Access, I can't change anything. If I execute sql queries with SQL Server Management Suite or if i start queries as SQL Agent jobs everything works fine.
Why are the rows locked in ms access after the query ran (even if it finished successfully)? and how can I unlock them or make it unlock itself right after the query/job ran?
Thanks
When SQL Server inserts new rows, those new rows are in fact exclusively locked to prevent other transactions from reading or manipulating them - that's by design, and it's a good thing! And it's something you cannot change - you cannot insert without those locks.
You can unlock them by committing the transaction that they're being inserted under - once they're committed to SQL Server, you can access them again normally.
The error message i get says, that the dataset has been changed by another user and if i save it, i would undo the changes of the other user. (and asks me for copying into clipboard).
This is different from "locked", and completely normal.
If you have a ODBC linked table (or form based on the table) open, and change data in the backend, Access doesn't know about the change.
You need to do a full requery (Shift+F9) in Access to reload the data, afterwards all records can be edited again.
Got the solution for my Problem now.
I had to add a timestamp row into the pricing table, so access could recognize the change.
Access loads the data into the front end when the table is first accessed. If something in the backend changes the data, you need Access to refresh it first, before you can edit it from the front end (or see the changes).
Do this by (in Access) by closing and reopening the table, or switching to the table and pressing shift-F9 as Andre suggested, or programmatically using a requery statement. You must requery, not refresh, for it to release the locks and register the changes made in SQL.
I have this project that would require users to check in/out through a finger print reader ZK SF200.
The system that I am building needs to fetch new data that is added into this machine's database which unfortunately is a MS Access mdb file.
In my limited experience in MS Access databases, I managed to link this file to my MySql database table which allows me to manually do the insert from MS Access.
All I want to do now is to create some form of trigger that would add data to my MySql database when new rows are inserted into the MS Access table.
This problem would have been solved if the file type was .accdb because we can use After Insert events however it is an mbd type so those are not supported.
Any idea on how I can solve this matter ?
As a final note: I am willing to change DBMS in case MySql is the obstacle here. Would creating a linked server or doing sql server replication through mssql 2008 r2 work ?
EDIT: I need to insert data to MySql table because I have a trigger implemented there which does its side of logical manipulation of the data (ex: Increment the number of visits for the customer, check if customer subscription has expired or not and update the customer status accordingly)
Thank you.
Linking a table in MS-Access to the ODBC source is probably an answer for you. The table in MS-Access will be more like a view on the source table. Any DML operation (INSERT, UPDATE, DELETE) will be synced immediately with the source database. You will not need any trigger, which is not available in MS-Access (unless some VBA expert knows a solution).
The Linked table technology is default available for SQL-server, but since it uses ODBC I quess you can use it with MySQL too.
I recently upsized an Access 2010 database to use SQL 2005 as the back end database using SSMA for Access. The migration was completed without problems but now users are getting a write conflict anytime they try to change something, even text in a description field. SSMA inserted a timestamp field in each table, which I thought would prevent the write conflicts. Is there something I need to do to Access to force it to use the timestamp field?
The error is:
"This record has been changed by another user since you started editing it. If you save the record, you will overwrite the changes the other user made."
While researching this I've tried other approaches such as setting BIT or REAL fields to NOT NULL and inserting default values. This made no change to the issue. The write conflict even happens when updating an Nvarchar(MAX) field. I changed that field to Nvarchar(255) but the error still occurred.
I should point out that Access is using a workgroup mdw file for security.
Can anyone help point me in the correct direction? I've done several of these migrations before but never had this problem.
Thanks,
Joe
Ensure that that bit columns don't allow null. Ensure such bit columns have default set of false (0). Ensure All tables have a timestamp. Ensure that all tables have a have a primary key.
I am using MS Access 2003 under Windows 7 (64bit), with external linked table at MySQL server (5.0.51a-24+lenny5), connected via MySQL ODBC connector (using 5.1.10, because the newest 5.1.11 is buggy). When I open this table in MS Access and try to delete some records from it, I get following error:
The Microsoft Jet engine stopped the process because you and another
user are attempting to change the same data at the same time.
When I try to edit some records in the table, I get following error:
This record has been changed by another user since you started editing
it. If you save the record, you will overwrite the changes the other
user made.
Copying the changes to the clipboard will let you look at the values
the other user entered, and then paste your changes back in if you
decide to make changes.
However, when I do it via deletion or update query in MS Access, it works fine! I just cannot delete the records directly from the table.
I found out (see the detailed analysis below), that the problem is present when there are double fields with values with a lot of decimal digits. See:
CREATE TABLE `_try4` (
`a` int(11) NOT NULL default '0',
`b` double default NULL,
PRIMARY KEY (`a`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_czech_ci;
insert into _try4 values (1, NULL),(2, 4.532423),(3,10),(4,0),
(5,6.34324),(6, 8.2342398423094823);
The problem is only present when you try to delete/edit the last record (a = 6), otherwise it is OK!
The issue is documented:
http://support.microsoft.com/kb/280730 , proposing these 3 workarounds:
Add a timestamp column to the SQL table. (JET will then use only this field to see if the record has been updated.)
Modify the data type that is in SQL Server to a non-floating point data type (for example, Decimal).
Run an Update Query to update the record. You must do this instead of relying on the recordset update.
However, these 3 workarounds are not satisfactory. Only first could be, but this workaround didn't work - as expected. It probably works only with MS SQL Server.
Are there any other solutions/workarounds for this problem?
Additional details:
The MySQL server is just for me, nobody else is accessing it.
Insertion of new records was working fine.
Primary key is well defined for this table.
Restart of MS Access didn't help.
Deleting the link to the ODBC table and linking it again didn't help either.
Linking the table from brand new Access database didn't help.
Changing the MySQL database engine from MyISAM to InnoDB didn't help either.
There is no problem with permissions, there are all permission for this user#host.
I can normally delete the records from the MySQL console at the server without problem.
Trying to set MySQL Connector ODBC options didn't help: Allow big results, Enable automatic reconnect, Allow multiple statements, Enable dynamic cursors, Force use of forward-only cursors, Don't cache results of forward-only cursors.
I turned on debugging in MySQL ODBC connector, it created myodbc.sql log, but it didn't contain any corresponding queries when editing/deleting (don't know why).
More details about the structure of the linked table would be helpful, but I'll hazard a guess.
I've had a similar problem in both MS Access 2003 and 2010 when I included nullable boolean fields in the SQL Server linked table. Seems JET databases have a problem with nullable nit fields. Check out this answer for more information: https://stackoverflow.com/a/4765810/1428147
I fixed my problem by making boolean fields non-nullable and setting a default value. If your problem is the same as mine, but with MySQL, try doing the same.
I solved here the same issue. The solution was to remove Default Values from decimal fields in the table. I was able to keep decimal data type but just remove the default value I already defined before with 0.0000 and now I set to null and bug fixed.
My workaround was to copy the table data into excel, then use phpadmin to clear the table, then do the editing in excel and copy the 'new' data (ie, all of it, after editing) back to access.
I have been charged with maintaining a legacy classic ASP application. The application uses an ODBC system DSN to connect to a MySQL database.
We had to recently update the servers to satisfy some licencing requirements. We were on Windows, with MySQL 4.x and the 3.51 ODBC driver. We moved to a Linux machine running MySQL 5.1.43 and are running the 5.1.6 ODBC driver on the new IIS server.
Users almost instantly started reporting errors as such:
Row cannot be located for updating.
Some values may have been changed
since it was last read.
This is a ghost error, and the same data changes, on the same record, at a different time won't always produce the error. It is also intermittent between different records, as in, sometimes, no matter what values I plug in, I haven't been able to repro the defect on all records.
It is happening across 70 of about 120 scripts, many over 1,000 lines long.
The only consistency I can find is that on all of the scripts that fail, they are all reading/writing floats to the DB. Fields that have a null value don't seem to crash, but if there is a value like '19' in the database (note the no decimal places) that seems to fail, whereas, '19.00' does not. Most floats are defined as 11,2.
The scripts are using ADODB and recordsets. Updates are done with the following pattern:
select * from table where ID =
udpdated recordID
update properties of the record from the form
call RecordSet.Update and RecordSet.Close
The error is generated from the RecordSet.Update command.
I have created a workaround, where rather than select/copy/update I generate an SQL statement that I execute. This works flawlessly (obviously, an UPDATE statement with a where clause is more focused and doesn't consider fields not updated), so I have a pretty good feeling that it is a rounding issue with the floats that is causing a mis-match with the re-retrieval of the record on the update call.
I really would prefer NOT re-writing 100's of these instances (a grep across the source directly finds 280+ update calls).
Can anyone confirm that the issue here is related to floats/rounding?
And if so, is there a global fix I can apply?
Thanks in advance,
-jc
Have a look at MySQL Forums :: ODBC :: Row cannot be located for updating.
They seem to have found some workaround and some explanations as well..
I ran into a similar issue with a VBA macro utilizing 4.1. When upgraded to 5 errors started popping up.
For me the issue was that values being returned to VBA from MySQL was in a unhandled (by VBA) decimal format.
A CAST on the numbers when querying helped to fix the issue.
So for your issue perhaps the ODBC/ASP combination is recording/reading values differently then what you might expect them to be.