in a Windows Company network environment we have several users who access MS Access Databases via MS Excel VBA Programms.
For updating the Database we´re bound to a legacy system. For entering data we use normal Access Forms and normalized tables. The Excel VBA don´t query the normalized tables directly but use a different Access Database which containes non-normalized records. The latter is deleted (via the Kill Command) and newly created after each "session" for entering new datas in the forms.
So, if any user queries the database via an Excel Programm while the other programms wants to delete and re-create it, the deletion fails with the error 70 - access denied.
(I guess in the Excel Programms there are some bugs and not all connections are closed, that´s why a user who keeps the programm open for a long time will block the deletion for a long time - but i´m not in charge of those programms O_o ).
So, I´d like to get the windows login (or any other information) of the user who currently blocks the database when the error is thrown. Is there any way to do this??
Alternatively I´d like kick any blocking user out of the database when it´s supposed to be deleted - is there a way to set some kind of priority for the kill command??
Thanks a lot!
To find out who has a file open use PsFile with the path to the file being blocked.
In terms of your architecture, if the non-normalized records are generated by queries which are (or can be) stored in your Access database, you should consider pointing the Excel file to a query, rather than generating a whole separate file for this purpose. You use the "Get External Data" section of the "DATA" ribbon to insert refresh-able tables in your Excel workbook.
Related
I plan on using Excel as the front-end and Access as the back-end only. (all queries and forms are in Excel). A single Access database will be queried from multiple Excel files that will be located on the share drive (Linux server). Access tables contain memo, text and number fields.
Data will be sent to Access tables and records will be appended/deleted; all via Excel.
There will be multiple users interacting with a single Access database via multiple Excel files located on the shared drive. Users will be interacting from different workstations with Windows 7, all have Access 2010 and Excel 2010 installed.
This process works for me from my workstation but I’m not sure what will happen when other 4 people will be sending/appending/deleting records to the same Database?
How do I make this work? What settings do I need to check in Access to make this possible?
Any advice will be greatly appreciated since I’m fairly new to Access.
Thank you!
Access is a file-server, and not a data-server.
That's means when you do a query on an Access database, all the data are going to the client part, who process the query.
Let a query "get the books written by Kernighan" in your Excel. Excel will ask to Access (throught the ADO or DAO) : "send me all the books". Access will send ALL the books, and Excel will find the book written by Kernighan.
In the same way, if Excel (still with ADO / DAO) want to make an update, it does it localy. The Access database will just set up a flag to prevent conflicts. (btw, this flag is stored in the .laccdb file)
In your case, all that are done by the ADO/DAO layer, which will
send all the data
set a flag to prevent the conflicts if one data is in Edit mode
So, to be short : yes, you can do it ;)
I have an access database that users are connecting to with excel files. I have way of managing people who are logged on using Access. However, I do not have a way to manage people who are connected to the database using excel. It is my front in so I am not worried about the Data I just want to be able to edit forms and add features.
Splitting your database will help...https://support.office.com/en-ca/article/Split-an-Access-database-3015ad18-a3a1-4e9c-a7f3-51b1d73498cc
But you can also look into making the FE you release to users as an mde or accde file. These will compile your VBA code and not allow users to enter design mode to change anything so these files are slightly smaller and more secure.
Then you can make changes to the regular FE mdb or accdb files that you have, test those changes and then when you are ready to release a new version, publish them as mde or accde files and copy it over the old version (or make back ups first, and then replace).
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
In our call center we use Excel VBA to extract integrated data through Avaya CMS supervisor. We have been using the same code for years.
One of our supervisors cannot run the report with her windows NT login. She receives the OLE timeout error when attempting. Every other user can run the report if they attempt to use their NT at the same computer.
We don't have anyone who knows VBA or Avaya well enough to troubleshoot (a temp was hired to code). I am intermediate level at best and find nothing wrong with the logic - as I said earlier it runs fine for me.
When I asked our dedicated IT department if this could be a user profile issue they informed me all supervisors have the same "cookie cutter" profile given to them. They state it has to be an issue with the VBA code.
Is there any other troubleshooting methods I can attempt at this point? Besides user permissions with Avaya and the code itself is there anything else that could interfere with VBA? Thanks in advance
It's possible that it could be an issue with the User Account Control (UAC), if that supervisor has it set on a higher level than others. When the UAC is turned on, it restricts what you can do in VBA. To check the UAC level, open the control panel, then 'User Accounts', 'Change User Account Control settings'
One alternative to using Excel VBA to extracting data is to use a web browser based reporting tool with full permission controls that exports regularly to Excel. NetLert's N-Focus Plus reporting tool can do that - it pulls data from CMS, stores it to a database on a server (as a result, you can store unlimited historical interval data), lets you set up any number of permissions for unlimited 'supervisors' so they only see their data or their groups' data, and they can export reports to excel or set up their own automatic daily/weekly/monthly report distribution. It also ties multiple CMS servers together in a single web-based interface, and does real-time and historical reporting... check it out at http://www.netlert.com/nfocus_video_overview.php
I have a spreadsheet in Excel that connects to an internal DB using the odbc driver for the software (Action Request System). That works fine. Now I'm trying to move the Excel file to a SharePoint site so that our team can review the data and make notes in the same spreadsheet.
So, first I tried just moving the Excel file to the server, but realized that the connection saved in the file was pointing to the connection file on my computer. So I moved that to the SharePoint site, and this seems to be working... Except:
1) On some of the computers, it opens just fine. But I'd prefer it if the dialog that asks for the login and pw for the DB was customized.
2) On other computers, the software and drivers are installed, but not showing up in the user source list, so it throws an error. When the user goes to create a new connection, the driver is there, (so its not in the first list, but it is in the larger list).
3) Macs can open the file, but Excel 2008 can't do the macros and connections.
4) Opening the same file from the same site throws the Trust Center warning each time, even on the same computer/same user.
Is there a way to do any of the following?
Have a non-macro that keeps the user from saving (and thus overwriting) the sheet until it is confirmed that the user won't make changes to the connections/macros?
Allow the user to connect from a local config (in case they can set one up that works when the main one fails) so that they can connect using that one but not screw it up for everyone else.
Set the trust settings (local or on server, I suppose) so that any files from a specific SharePoint are always trusted?
Finally, and this is the big one...
Can you create a connection using a driver not on the local machine? If the driver is installed on a remote server, can Excel use that one? If that were the case, that would solve almost all other problems (Unless you're on a Mac).
I feel like I'm going at this slightly wrong, but since the team all need to see each others notes, our only other solution is to upload the data (from the DB) into a MySQL db so that they can make notes from their browser. This makes it more universally available, but forces us to script a lot of functions that are standard in Excel and create redundant DBs.
Wow! Access to the ARS via ODBC! I suggested that feature to the architect when I worked at Remedy HQ back in the nineties. Great times.
Anyhow, I think your approach of sharing an Excel sheet that connects to an ODBC source is not the easiest path. (As you've been discovering.) ]
ODBC is always a local driver, afaik. A client locally connects to ODBC. ODBC then can use the network to connect to the DB.
Instead, I suggest that you investigate setting up Access with a table that is remotely connected to the ARS system. You could then remotely open the Access table via file sharing as opposed to a dbms-connection. I believe that this would be easier to get going than your current path.
HTH,
Larry
It sounds like you are using a User DSN to make the connection. You can switch to a DSN less connection by using a connection string. If you need some help with that, can you post the code that needs modified?
First, thanks to both users that provided answers. Both of you were really helpful in getting my mind around the problem.
So, it turns out that while you can't easily connect to Action Request DB directly, AR does support Web Services.
Rather than attempt to make Excel, Access, PHP, or any other system deal with creating a Soap Client and handle the work themselves, I came up with an alternative that I think is fairly clever, if I do say so myself:
1) Created a php script that calls the Web Service with the requested data,
2) The script parses the response into a more generic XML form,
3) script echoes out the xml
4) Name the script "AR_Data_Request.xml"
5) Configure the directory, via the .htaccess file, to treat xml files like php
Now, I have a static xml file which always contains the most up-to-date data from Action Request. I can point any other apps (specifically Excel) to that xml file instead of having to write VBA code to query the web service directly (and still have to do it again for php).
The only problem is that I can't get the php to connect to the Web Service (doh!) but that will be my very next question.
Thanks again!