I have problem with MS Access 2007 table connected via ODBC to MySQL server (not Microsoft SQL Server).
If unique identifier in MySQL table is BIGINT - all cells content is displayed like this: "#Deleted".
I have found this article:
"#Deleted" errors with linked ODBC tables (at support.microsoft.com)
and it says:
The following are some strategies that you can use to avoid this
behavior:
Avoid entering records that are exactly the same except for the unique index.
Avoid an update that triggers updates of both the unique index and another field.
Do not use a Float field as a unique index or as part of a unique index because of the inherent rounding problems of this data type.
Do all the updates and inserts by using SQL pass-through queries so that you know exactly what is sent to the ODBC data source.
Retrieve records with an SQL pass-through query. An SQL pass-through query is not updateable, and therefore does not cause
"#Delete" errors.
Avoid storing Null values within any field making up the unique index of your linked ODBC table.
but I don't have any of these things "to avoid". My problem is in BIGINT. To make sure if this is it I created 2 tables, one with INT id, one with BIGINT. And this is it.
I can't change BIGINT to INT in my production database.
Is there any way to fix this?
Im using: Access 2007, mysql-connector-odbc-3.51.30-winx64, MySQL server 5.1.73.
You can try basing the form on an Access query, and converting the BIGINT to an INT using CInt() in the query. This happens before the form processing. Depending on your circumstance, you may need to convert to a string (CStr()) in the Query, and then manually handle validating a user has entered a number using IsNumeric. The idea is to trick the form into not trying to interpret the datatype, which seems to be your problem.
Access 2016 now supports BigInt: https://blogs.office.com/2017/03/06/new-in-access-2016-large-number-bigint-support/
It's 2019 and with the latest ODBC driver from Oracle (v 8.0.17) and Access 365 (v 16.0.11904), the problem still occurs.
When the ODBC "Treat BIGINT columns as INT columns" is ticked and in Access support for Bigint is enable in options, the Linked tables with Bigint #id columns (the primary key) shows as deleted. Ruby creates these by default, so we are loathe to fiddle with that.
If we disable the above two option, Access thinks the #id column bigint is a string and shows the data. But then the field type is not bigint or int anymore.
This is quite pathetic, since this problem is almost 10 years old now.
The MySQL driver has an option to convert BIGINT values to INT. Would this solve the issue for you?
Related
I created a pair of Access (365) files. One is a front-end with forms, the other is all tables. I then migrated the tables over to SQL Server (2008 R2) on a remote machine. I got the front-end to talk to the SQL server instance using an ODBC connection. I have several screens which work on the tables, some are bound to the tables, some are unbound.
I can update data in existing records and I can remove records, but I can't insert any. This is happening on both bound and unbound forms. I saw posts that said I needed to:
-Set a default of ((0)) for all BINARY fields and set so that they can accept blanks,
-Change all NVarchar() fields to Varchar() fields, and
-make sure every table has a timestamp field.
I did all of those, but no luck. Any thoughts? Thanks!
Oh, yeah, I also made sure every table has a key.
Found it! The field was specified as a Primary Key, but its 'Identity' property was set to 'no'. Changing that fixed the problem...Thanks again, all!
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 am attempting to use the MySql Entity Framework provider for a small project. I've always encountered "quirks" when working with the MySql Connector (the one developed by MySQL, not DevArt).
The latest thing I found was that my entities generated from the database are getting long instead of int for their Id fields even though the type in the database is specified as a SIGNED INTEGER, AUTO INCREMENT, PRIMARY KEY.
The only thing I can think of is that LAST_INSERT_ID() always returns long. Since my entities rely on the database to create the identity value, perhaps MySQL Connector makes the Ids long to accommodate the id retrieval after insert?
The easiest workaround for all the issues I've encountered would be to just use SQL Server. However, the target for this app is shared hosting. Even if you pay for a SQL Server add-on, most shared hosts limit the SQL Server instances to 200MB and only allow 1 or 2 databases. That is just too small in my opinion. The same hosts offer several 1GB MySQL databases for free. If you outgrow that, you probably should have a dedicated box anyway.
MySQL will allways return a 64 bit int (or a BIGINT) instead of a 32 bit int. That's why you're getting a long instead of an int.
See this bugreport: http://bugs.mysql.com/bug.php?id=64084, and the MySQL manual on LAST_INSERT_ID(): http://dev.mysql.com/doc/refman/5.5/en/information-functions.html#function_last-insert-id.
I'm working up a database in PostgreSQL (8.3) that users will interact with (update and query) via Microsoft Access 2003. Several tables have primary keys defined as 'serial' in PostgreSQL. These columns, when linked into Access, show up as 'Number' and don't auto-increment when inserting new data into the tables via Access. Is there a way to make serial primary keys work through Access? Maybe serial isn't the appropriate type? All I need is something unique that is automatically generated by Access when a user starts a new record.
A serial is a integer with a default value from a sequence. If you don't insert anything in this column, the default value is used. That will always happen, no matter what client you use. Access 2003 works fine as a client, also with default values.
Tip: Ignore this column in Access and let the database use the default value.
I need a list of recommended MySQL data types to use when using Microsoft Access as the front end. Can anyone point me to a succinct article on the net, or post a list here please?
Check out this: Using Connector/ODBC with Microsoft Applications
For all versions of Access, you should enable the Connector/ODBC Return matching rows option. For Access 2.0, you should additionally enable the Simulate ODBC 1.0 option.
You should have a TIMESTAMP column in all tables that you want to be able to update. For maximum portability, do not use a length specification in the column declaration (which is unsupported within MySQL in versions earlier than 4.1).
...
Access cannot always handle the MySQL DATE column properly. If you have a problem with these, change the columns to DATETIME.
....
Here's a comparison of MS Access, MySQL, and SQL Server datatypes.
There are a lot of tricky issues to watch for; in some cases, Access and MySQL give the same name to different data types, e.g.
TEXT in Access is 255 characters (similar to MySQL's TINYTEXT)
TEXT in MySQL is 65535 characters (similar to Access's MEMO)
So if you use a TEXT field in MySQL, you'll have to access it as a MEMO in Access.
Number types can be tricky, too. MySQL has both signed and unsigned versions of each type, but Access doesn't. For example,
BYTE in Access is equivalent to MySQL's TINYINT UNSIGNED
INTEGER in Access is equivalent to MySQL's SMALLINT (signed)