Situation : I made an Access Database which runs 4 Update Queries + 1 SQL update statement in an AutoExec Macro as soon as a user opens it before displaying all the updated information in a Form with conditional formatting applied to it.
This database will be used (editted/read) by multiple users at the same time. So far, if only 1 user opens it it's fine.
But if multiple users do, the 1st one who opens it sees the Form after about 10 seconds whereas the 2nd sees it after 60 seconds or more and navigation through it is really slowed down.
Any ideas on how I can fix this ?
I currently think that this can be fixed with the Advanced Client Settings from the Access Option and these are my settings at the moment :
EDIT : The Database in question is NewVersion.accdb and I asked all users to open this one.
Related
I know that there is user parameter CLIENT_SESSION_KEEP_ALIVE, which defines wether session should stay alive forever or be killed after 4 hours of inactivity.
Mine is set to False.
show parameters like 'CLIENT_SESSION_KEEP_ALIVE';
But in Snowflake UI on tab Account > Sessions I see my old session, which started almost 2 days ago.
When I check this session in QUERY_HISTORY table, I also see that there were no queries for almost 2 days.
Why my session is not getting killed? Which settings should I change?
If there is no way to kill such sessions automatically, then I'd like to kill them manually using select system$abort_session(<session_id>); command.
In order to do that, first of all I need to get list of active sessions, that I see on UI tab Account > Sessions.
Is there any system table/view which can provide such data?
Per the Snowflake Documentation, the CLIENT_SESSION_KEEP_ALIVE is only for ODBC, JDBC, Python, and Node.JS client connectors. It does not affect the UI.
https://docs.snowflake.com/en/sql-reference/parameters.html#client-session-keep-alive
I have an access database that has been used for many years, converted from Access 2000 to 2007 and was fine. In the last couple weeks it has been doing strange things!
There is a form for 'editing' a record. When the user clicked on the button to open this form, a small white box appeared and said 'Record Deleted'.
After that, the database was corrupted. I support this database and I can not even get into it in design view. When I try to open it (holding the shift key down while opening it), it takes a while, then it displays the Access design page that has the 'blank database' icon and to the right it lists the frequent opened databases.
So, I can't even get the to objects. The only option I had was to restore from a previous night backup. This meant the users lost all their work for the day. Today, one week later, it has happened again. All the users work was lost because I had to restore from backup.
I don't know where to begin to trouble shoot this since I can not get into it in design view when it has become corrupted. Looking for any suggestions to debug this. I can use a copy of the database I had restored.
Thanks
As a first and most important suggestion. You should split your database.You can do this from the database tools tab on top. By doing this you will have a seperate back end independat of the front end and your client will not loose any data as if they get the error / corrupted database it would not affect the data secured in the backend
Second I havent had the exact same error but in the past I have faced instances where the forms just dont work. a recommendation i read somewhere was to create a new blank form and copy over the elements from this form onto that and delete this form. I doubt if there is any problem with the VBA but it would be worth compiling the code to check.
Apologies if this does not help much, but I hope the first suggestions helps protect your client data in the instance your database crashes.
First, check if any automated VBA code or macro is running on OnOpen, OnLoad, OnCurrent, AfterUpdate, OnDirty, etc. events of the troubleshooting forms. Simply open the VBA window and look at code on the specific form's module. Or in the case of macros, open form in design view and check the Event tab of Property Sheet (and the same for specific buttons, textboxes, etc.). There may be DoCmd.RunCommands occurring when users interact with form controls.
Also, if you find yourself unable to open forms or deal with a corrupted database, consider beginning with a blank Access .accdb file and import all objects from the previous Access 2000 .mdb file. And if specific controls don't function properly, recreate them as needed.
As mentioned above, split your database between BackEnd (only tables) and FrontEnd (forms, queries, macros, modules) which prevents corruption, efficiently runs systems as only data is sent across the network and not whole application items, and overall fosters a better multi-user environment. Each user can have copies of the FE on their local machines but all will connect to one BE on a shared network. To help, Access 2007-2013 has a button for this on the Ribbon under Database Tools.
I have a database that i have split into 3 pieces: a Front End, and two back ends that contain tables. Copying the front end to a users desktop cuts the runtime from 90 minutes to 30 minutes. However, when I move the back end to the desktop as well, the runtime is less than 8 minutes. The problem I am facing doing this is that I had to manually update the table links.
Is there a way to make it so that Access automatically updates the links based on what users computer it is on?
For example, I created a batch file to move the database files from the shared drive to a folder on the users destop using:
"%userprofile%\Desktop\Folder1\"
as the location to move the files to. "The "%userprofile%" automatically identifies the user and route the files properly. I didn't know if there was something similar to automatically update the links in Access.
Please let me know if you don't understand what I am trying to ask.
Assuming the 1st backend is on the user computer, and the 2nd backend is on the shared network, I think what you can do is create a qry upon opening the database to update the user's table, then after exiting, a 2nd qry that will export user's table back to the 2nd backend on the shared network. You'll have to add a field in the table so that your database knows which record to be added or to be exported.
We have a Practice Management system that is about 15 years old. I've been working on it for about 12, and I've never encountered this problem until just recently, and we can't figure it out.
It is written in VB6 which uses ADO/JET to access an Access .mdb file on the network. The application opens the connection when it starts, keeps it open while it's open, and closes it when it exits. It does a LOT of stuff with the DB - the system deals with Patient Accounts, Charges, Payments, Scheduling Appointments, and about a million other things. We have dozens of clients that use this program, each with their own DB and most of them 'offsite', where they have their own server, some number of workstations, between 1 and 20 users, pounding away at the system 24 hours a day, 7 days a week, and except for the occasional DB field bug or having to compact/repair DBs, it's pretty stable.
About 3 weeks ago, we started seeing a problem that we hadn't seen before.
We have an 'in-house' system setup for us to use: the DB is on our Server which houses maybe 10 other DBs, and only a couple of people connect in to this system.
We started noticing that if someone logged into the system, went straight to our Scheduler screen, and then sat idle for about 5-10 minutes, they might get "Disk or Network Error", or "Cannot find the input table or query X on database Y".
What's strange is that it SEEMS to happen only when 2 or more people are logged into that DB from different computers, and then one of them will get the error (Randomly?) but the other 2 users will be fine.
There is a Timer on the 'main' MDI Parent form of the system which wakes up about ever minute (there are some things which will change the interval to a shorter interval, and there are some things which disable the timer, but we don't think either of them are happening in this situation). It performs a pretty basic SQL Query on the DB: SELECT loggedin FROM Users WHERE UserId = 'DBUPDATER' THIS is the SQL Query that seems to be ALWAYS triggering one of those errors.
There is also a timer that runs about every 2 minutes while a user is logged in to check for emails and a few other things that would be running during this time.
And since they are on the Scheduler screen, there's a timer on there that runs every 30s or so which will check the DB to see if any changes to the scheduler have been made to see if it needs to refresh the screen or not.
There are some other strange things:
The DB and the Users table seem to be perfectly fine. When the person who gets the error logged into the system - usually only 5 minutes earlier - the system HAD to look at the Users table to mark them as Logged in, and I'm almost 100% sure that the query that it's dying on had been run at least once - probably 4-5 times before it dies.
Once a user gets this error, if they leave the Error's MessageBox on the screen (not quit the .exe), if they try to access that DB file in any way, they get "Disk or Network error" - this includes if they try to open that DB in Access. HOWEVER, they can still get to the Network just fine, and even open up other mdb files IN THE SAME FOLDER as the one they can't open. OTHER PEOPLE on other computers can open that mdb without any errors. Once the user acknowledges the Error, and allow the exe to close, they can open that DB file again just fine.
I'm told that this is not in anyway a Network issue. Our IT guy says he's run pings and traces and all sorts of tests to ensure that the network connection is not getting dropped.
I've also run some things on the DB to make sure it's not corrupted and it seems to be fine - and we get it to happen on other DBs.
If anyone has seen anything like this and knows a possible fix, I would greatly appreciate it! Thanks!
New Information (9/5/13 - 10:30am)
We noticed that at the same time we get this error, in the errorlog on the computer that gets the error is a Warning Event that says:
{Delayed Write Failed} Windows was unable to save all the data for the file \MEDTECHSERVER\MEDTECH DATA\VB\SCHEDTEST2\MEDTECH.MDB; the data has been lost. This error was returned by the server on which the file exists. Please try to save this file elsewhere.
I am developing a system in Access talking to a Sql Server backend. I can connect with two separate accounts A and B so that I can control permissions. In particular I have a view which is accessed via a pass through query which is denied to A but allowed by B.
Normally selection of A or B as the login is related to which Access Security Group the user belongs in, but I have set it up so that people in the Admins group (ie me) read the login from an internal access table. I have also created a form (and associated code) that allows an Admin to change this value.
This all works great and does its job perfectly - provided I start up Access from scratch.
It detects I am admin, reads the last value I set in the internal table, connects to the server with the correct login string (I loop deleting and re-creating all the tabledefs using this new connection string) and then displays my first form. I navigate to a button that runs the pass through query. When I click that button it recreates the pass through query, by deleting one with the same name and recreating it with the correct connection string (A or B login) before then running it to output results. If I am A, then it fails with a permission error (which I display and inform the user about), if I am B it works and I get the results.
I have added a system to attempt to change this on the fly for testing purposes. Having changed who Admin should login as (by writing to an internal table), it recalls the startup code, which loops through deleting and re-creating tabledefs and then puts me back at the intial form.
HOWEVER - If I now navigate to the button that runs my permission controlled query, it still deletes and re-creates the query def from scratch, but when I run it, it seems to run in the context of the SQL Server Login it set when I first started access, and not the new SQL Server Login I have just re-created everything with. So the query will run when it shouldn't (of visa versa).
If I exit Access and try again - it starts working properly again.
The only conclusion I can draw from this is that somewhere inside of Access it is caching the ODBC connection string - and instead of using the new one is using the old.
So my question is - is my conclusion correct, and if so how can I tell Access to clear its cache.
I am developing in Access 2010 - for a system that will ultimately be running in an Access 2000 environment - so the file format is an .mdb in the Access 2000 format.
I came to this topic because I had the same question: "How to clear the cache in Access 2010?"
In my case, the problem was that my application somehow "remembered" the entire path to my linked photos, even though I referenced only the file name. One of the links above lead me to search under "File > Current Database > Caching Web Service and SharePoint tables." The option to "Use the cache format that is compatible with MS Access 2010" was already checked, but I enabled the check box for "Clear Cache on Close" and closed the database.
Voila! All previously cached values, including the values for my linked photos, were cleared out. It doesn't appear that this setting affected my ODBC DNS-less connections, but I haven't confirmed this.
**TO CLEAR CACHING, go to File-->**OPTIONS-->Current Database, and scroll down to Caching Web Service and SharePoint tables.****
Can this page about ODBC linked access password reset be what you're looking for ?
As far as I know, there is no way to clear this cache. If you execute a query and supply a different UID/Password for that query, then the permissions you obtained from that act will remain in effect until such time you close down Access.
Thus if you execute another query and supply a "differnt" UID/password, and then later own execute another query with “lower” permissions, the other cached UID/password will be used. So you can (and will) have multiple UID/passwords cached at this point in time - you have no control over which one is used.
The only way around this would be to adopt a separate ADO query – this to my knowledge does not cache the credentials like when using DAO queries.