I have to prune a large table in MS Access. Every time I delete a row, Access asks me if I really do want to delete it. This is driving me nuts. I can't find a preference about this in Options. Is there a workaround?
before executing delete query put the below statement. This command makes system messages off
DoCmd.SetWarnings False
after executing the query set to true again.
Related
I have a problem using an Access Application connected to a MySql Database.
I test UPDATE on one small table with a VBA procedure, using DAO
UPDATE tblFormateur
SET Prenom = 'Werner'
WHERE Nom='HEISENBERG' "
The first time I run the query, it's ok.
But if I run the same query, without changing the value,(keeping Prenom = 'Werner')
I get an error message saying that the query has not been executed,
due to a lock violation.
If I run the query again, but with a different value, e.g Prenom = 'Peter',
the query is executed without error.
On the other hand, If I do the same experiment with ADODB,
I do not get any error.
One can say: let's go with ADODB!
The problem is that the Access application Forms use DAO, not ADODB!
So all the forms won't be able to either add new records or update records.
Did you experienced the same issue?
Are there some parameters of the ODBC driver that needs to be set?
Thank's advance for any help.
Windows 11
Access Office 365
ODBC connector 8.0 CE
If you have a linked table as form RecordSource and you run an update query, it always give you this error.
The error appears because Access do not detect any changes. If you have a field with value 'Test' and than you delete this value, rewrite 'Test', Access doesn't detect any changes because the value is the same.
To bypass this error you can make a random field that add n + 1 before running your query. When you open the form, field is set to 0, before you run the query is 1, next time is 2 and so on.
Access will detect changes to the form and won't give you this error.
The issue I'm having is that many of the form controls trigger events that make changes to other fields bound to the form which results in a write conflict. I have tried placing If Me.Dirty Then Me.Dirty = False to save any changes from user interaction with the form, but I still receive the write conflict regardless or where it is placed.
For example, this will result in a write conflict:
Me!pnls_rte_profiles_id = Me!pr_rte
Me.Dirty = False
I'm using MS Access 2019 with a rather large database. The forms record set comes from 12 different tables linked through an ODBC connector. Each table has a primary key and a timestamp, but the timestamps aren't pulled as a part of the query for the recordset.
SOLVED:
So I found the issue stemmed from 2 places.
I forgot to include the other tables primary keys in my SELECT query.
Updating a records value to what it already was caused an issue with the MySQL ODBC connector.
The fix to 2:
Open the ODBC manager and configure the connector.
Under the Connection tab check Allow big result sets
Under the Cursors/Results tab check Return matched rows instead of affected rows
Relink tables in MS Access
Credit: here
Hopefully this helps others avoid days of struggling like I did.
I have an Access Database connected(linked table) to an Oracle database.
I wrote some Select queries. Everytime I run it, I get an "Oracle ODBC Driver Connect" input box.
Is there way to write a vba macro to enter username and password (auto fill) and Enter Ok.
Trying to set up an auto run for macros in this Access db.
Any help is appreciated.
As pointed out, when you link the tables, you are given an option to save the password in those table links. If you missed this step, then you will get that ODBC prompt.
THIS HAS ZERO to do with you writing select queries. The simple matter is try clicking on one of the linked tables you use in such quires. Either you get an ODBC prompt or you do not.
If you do, then of course you going to get such a prompt when you write a query. YOU WANT to FIRST get the table links working without an ODBC prompt and THEN write those queries based on the linked tables.
So get the linked tables working first. Forget about and don’t’ worry about your queries you are writing. Until such time that a simple click on (opening) a linked table works and does not throw out the ODBC prompt, then you are looking at the WRONG problem.
Once you get your linked tables working without a prompt, then your queries will also work without a prompt.
So you have two choices to fix this problem.
Simple re-link your tables, and ensure that you select [x] check box during re-link to save the password.
The prompt you missed and want to select is this one:
Now if your tables are already linked and you run the linked table manger, you WILL NOT get this prompt anymore. So you have to delete the table links, and re-create.
Of course deleting the table links can often result in the linked table names being changed, and that can be a pain, especially if you have a LOT of linked tables. Only you can make this judgement call as to what is less work. If you have just a few tables, then just delete them, and use the external data -> then in the import and link secton, choose ODBC and you can add the tables, but REMEMBER to select (check) the above save password box as per above that you missed.
Now, most people over time wind up with some table re-link code VBA. So if you have suc re-link code already working and handy, then simply re-run that code with the user/password included in the connection string you use in that code. Of course if you don't have such code, then the above linked table manager in Access is a code free solution and is obviously your best choice and course of action.
So in place of above, you can find some table re-link code that will force (save) the user/id in the table links for you.
However, if you don’t want to delete + re-create all those tables, and you don’t have already setup some re-link code, there is also another (3rd) choice.
In your application start-up code simple execute a one-time logon. If you do this, then the ODBC prompt will not appear when you use the linked tables and hence also not appear when you attempt to run/build/use a query based on those linked tables.
The code to execute a one-time logon will look like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
Above code run ONE time on start-up of your application will thus eliminate the ODBC prompt(s) when you click on a linked table. And of course once that issue of linked tables is resolved, then of course creating or clicking on your query or running those quires will now ALSO work without the prompts.
You can NOT auto fill that prompt, you have to take CORRECT steps in the first place to PREVENT that prompt from appearing. So to answer your question?
No, you can't write code to enter the requested prompt, but if you link your tables with the password saved, or execute the above logon code, the prompt will NOT appear in the first place.
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.
So I've developed this Access 2007 application with about 2 forms, a lot of VBA code and a bunch of tables.
Now the business wants to run this off a network drive (call it G:\ for example). My current solution (which I've already implemented is have a table similar to:
__________________
|Setting | Value |
==================
Updating 1
UpdateBy User1
So let me give you a context. When the application runs there is a button called "update" which updates the local table from a remote server so we can apply filtering. Now when two people (user1, user2) launch the application, and one person clicks update then the updating field is set to true, and the updateby is set to their name.
So User number 2 tries to update, it checks if the updating field is true, if it is then it gives them a message (to user two, not to user one).
It works beautifully right now, but here is the problem: Lets say user1 is updating, and closes his program (or taskkills it) or the power disrupts, then the application shuts off with the updating field set to to true. Now no matter who launches it, they can not update because its "already updating"
Can you guys think of a solution to this? Maybe a workaround?
Consider a different locking strategy. In the click event of your "update" button, you can first open a recordset based on your tblUpdateStatus (the table where you've been writing UpdateBy) with dbDenyWrite + dbDenyRead options.
Set rst = db.OpenRecordset("tblUpdateStatus", _
dbOpenTable, dbDenyWrite + dbDenyRead)
Then do your other operations for the "update" button. Afterward, close and release the recordset ... which releases the tblUpdateStatus lock.
Trap the error when a user is unable to open the recordset (because another user has the table locked), give them a message to try later and exit your click event subroutine.
With this approach, when user1 locks tblUpdateStatus but exits Access uncleanly, her lock on tblUpdateStatus is released. You may not even need to update tblUpdateStatus unless you want to record which user has it locked.
See Create and Use Flexible AutoNumber Fields (from the Access Cookbook) for more details about using a recordset with dbDenyWrite + dbDenyRead.
Please do not run an Access application with more than one user when you have not split the database. It will cause endless trouble. The data portion (back-end) should be put on the server and the code and forms (front-end) should be put on each users desktop.
More information: http://support.microsoft.com/kb/162522
Read my article on why you split here:
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm
In the above, I don't just tell you to do this, but I tell you WHY you split.
It should help you a lot in terms of users tripping over each other.