So we have a writable database that a lot of our product / data people use. This database has recently been migrated to Managed Instance.
We're working on getting them connected to be able to write/update DB records via Access, a functionality they've had before.
Currently, we're looking at starting them from scratch.
We can't seem to find a way to create a connection that allows for updating or changing records. The connection we're setting up allows them to insert / create new records, but the second that create goes through, even the newly created record can't be edited. We get a standard MSAccess writelock error. This is the case on EVERY table we open. Even ones that are essentially never touched.
Here's how we're connecting:
Network: The machines running msAccess are on our "main office" connection, which is peered with a vnet to the Sql Managed Instanfce. We CAN connect to the sql managed instance via ssms from this place, so it shouldn't be a networking issue (we can also insert records, so same thing)
Permissions: I've made sure that I have full sysadmin permissions via our az-sqlprod01-admin AAD group. I can do this same action in SSMS
Method:
Access > External Data > Linked Table Manager > Add:
Next Screen is Table Import, So that once that's finished we have the full table import list. We import those tables without issue.
Once there, I can bring up any table, try to edit anything, and it gives me the write-lock error at the top of this screen.
My Need: is there a way to connect MSAccess to a SQL Managed Instance without getting write-locks 100% of the time?
Related
I have three Access database MDB files with various tables I need to upsize to SQLServer. I need to be able to update the data regularly. I am using an SSIS package in Visual Studio. I have it set to use the 32 bit version for this project. I have one of the databases running just fine. Using the same techniques on the next database I create an OleDb connection manager using the Access 16 connection and the connection tests fine, I drop down the tables drop down and it finds the table names just fine. I pick a table and hit ok and it comes back with:
Exception from HRESULT:OxC0202038
I got these databases from another source. Two of the three were set without security. Being older MDB's they have the ability to have user level security. The table in question was in the one database that had security set to admin only. The deceiving part is that the oledb connection could find the table names at all with security set so I should not be able to read them. The ambiguity of the error message was not all that helpful either. But, once I reset the user level security to allow full access things worked fine.
I'm in a situation where I need to use a SQL server as a back end to Access 2010 database. The problem is that the server is only accessible with a SQL login. This isn't a big problem for the table part of the database - one login to the server connects all of the tables. The problem is with stored procedures that must be called. Since these are not under the ODBC umbrella, each query requires a login. I can't seem to find a way around that. Currently, I'm trying setting up pass through queries in Access, but once again - each query has to be logged in to individually. Is there a way to set up something (query setting, ODBC setting, VB structure or anything!) that will get around this problem of having to log in every time an SP is called?
I'm trying to avoid writing a whole big wrapper that handles the login and holds the password for later connections...
Is there a way to locate the underlying SQL in a ServiceNow (SNC) instance using MySQL as the database platform? My user account doesn't have access to watch the PROCESSLIST, so I was looking for a table possibly that stored an SNC based report's SQL.
For example, I've created a report in SNC and execute it manually. I would like to be able to go out to some table in the database to see if the SQL for which that report is based upon is available outside of watching the PROCESSLIST.
Ignoring the question of "why?" (normal hosted instances don't expose direct database connectivity to end users, so I'm curious what you plan to do with the raw sql), you can get the sql that was used anywhere in the platform by activating sql debugging. This requires the admin role in the appliation.
To activate sql debugging, in the left nav, go to System Diagnostics > Session Debug > Debug SQL
This will cause sql statements for every transaction in your session to be written to the bottom of every page load. It also includes the sql for the previous transaction, so if you need to get the sql for an AJAX transaction or something, just trigger it, and then navigate to some other page (/ui_page.do is an easy one that doesn't load anything, but still gives you your sql debug output)
We have a system that uses replication to allow folks in two different locations to work with a common database back end. The network is not high quality, and slow so I used replication to put a back end at each location and keep them synchronized. Synchronization is done through the Replication Manager and synchronizer running on a schedule. This has been working great for the past two years. The system was originally developed and used with Access 2007 but with the back end in mdb format. So now the client is up to Access 2010. The client wanted some changes to the back end, entailing some new tables and new fields added to existing tables. No problem I think. I went to the site and opened the Replica set design master using Access 2010 and added the new tables with no problem. Then I tried to add the new fields to existing tables. I could do that in design view but when I tried to save the changes I get a message 'Operation not supported for this type of object' message. I banged my head against the wall for a while thinking I was doing something wrong, then gave up working at the client facility. I did run the synchronizer before leaving and the new tables propagated properly to the other managed databases. This part is working.
After returning to my office I thought possibly this is an Access 2010 issue. I fired up a virtual machine with Access 2007 on it and a running replication system of the same database. In Access 2007 I could open the design master and add fields to existing tables with no errors and the changes would save. Is this an Access 2010 issue or is there something else going on? I'd hate to have to re-install Access 2007 on one of the client computers to make these changes. I have the same system running on my Access 2010 machine and I can duplicate the 'Operation not supported for this type of object' issue using Access 2010 in my office. Any thoughts?
Thanks in advance for your assistance.
Old thread but I have also run into the same problems. I found that using Access DDL (e.g. ALTER TABLE) in the SQL window works to modify table design in a replicated database in Access 2010. It won't allow you to modify an existing field/column but you can at least add or drop fields from existing tables. You can use DDL to modify an existing field by adding a new temporary field to your table the way you want it, copy the data from the existing field to your temporary field, then drop the existing field. Then add a second new field with the name of the field you deleted and copy the data over from the temporary field. Then delete the temporary field. More Access DDL info here
Does anyone know how to import .dbf file into MS ACcess 2007?
Do you want to do this programmatically?
MS-Access has option to import the tables OR you could create a Linked Table.
EDIT: Open the MS-Access MDB, goto tables. Right click -> Import -> Choose the appropriate database type (could be dbf in your case).
Well a VBA approach to pragmatically pull this information is to create a connection object connecting to the directory of the tables you want to pull from.
After that open a recordset to query what you need from the tables against that connection. A big benefit of directly connecting and scanning is that your not bulking up tables in your database to push you closer to your next repair/compact.
In order to get this connection however I needed some kind of ODBC connector, something the network admins came and installed behind my back when I switched to a new work PC and it suddenly broke upon connection. If this is something you would be using on other users PCs who won't have access to this (if this is a query you will be performing on a normal basis) it may not function properly for others...