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.
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 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?
I have inherited a database which is an MS Access 97 frontend with a MySQL V5.2 backend. In MySQL I have a table with a Primary Key field set at VarChar (50). This was setup because our reporting system uses an alpha numeric identification. The same field in the linked Access table is set at text. At present, I have a query which returns new sequential values over a set value (eg) >S/1234 to generate values which are then added to the above table. The users then use these values to print a series sequentially numbered reports. However, I have now come to value S/9999 and users can no longer use the query to obtain values > S/9999. Any ideas of how to solve this problem would be appreciated. Thanks.
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 support users who use MS Access as a front-end for viewing some Oracle tables at our intstitution. Their typical use is to write ad-hoc queries with the Access querybuilder, and also they LOVE Access because it lets them build printable reports without having to submit to the lengthy & expensive programming-request process through our tech support department.
When creating a link to an external table, they are sometimes asked to identify the primary key of the table. Of course, how can they possibly have any idea what the primary key field(s) would be?
My question is this: Why does Access want to know what the linked table's primary key field(s) is? Indexing should be happening in the source db, shouldn't it?
We had an issue recently when users started moving to Access 2007 that was finally "fixable" in two ways: 1) new ODBC connection, or 2) identifying a different primary key column for the linked table. My tech support tried to insist that I would have to modify my practice by telling my users to select the correct primary key field. I contended that it shouldn't matter. But I can't dismiss the thought that MS Access wouldn't be asking if it didn't matter for something. Just not sure what that might be.
Note: the "issue" is described in this post: Access 2007 to Oracle 10g linked table -- query with flawed results, but no errors thrown
If your users just need read-only access, for querying and reporting, have them click cancel in response to Access' question about which field(s) to use as primary key. They should still be able to create a link but it will be read-only.
If your users need to modify data in the linked Oracle tables, give them copies of an Access database file which you create for them. You set up the linked tables, and the connection properties are stored in the link's TableDef ... Access doesn't need to refer back to your DSN for that link afterward. So the users won't need the DSN, either.
How will the users know what the table means or how to join it to other tables unless they know what the keys are? Knowing what keys exist is pretty essential to get useful results out of a SQL database.
Not only uses the pk for update. Also when making an heterogeneous join, ie. between odbc table and local table or tables from different odbc sources, the access need to get all the data to local to do the join. Having the pk can loop doing multiples querys to the external source using the pk. This is really good for small local tables and long-long odbc tables.