I have a business user I am migrating to Snowflake that has many MS Access reporting processes that use MS Access Linked Tables that he is attempting to redirect to Snowflake through an ODBC connection. If his ODBC connection specifies a Database, he can see contents of the linked table. If he tries to link a table in a different Database, MS Access can find the table in list of objects but cannot open it. It is like the process to find the table is using the full data dictionary but when you try to link it, it forms a query that lacks the database qualifier.
We have tried most all qualification of including or omitting entries out of the ODBC connection properties including the database. We can think of two work-arounds but neither are ideal because there is a large user community and the reporting is complex and vast. The two backup options are to create a separate driver for each database or to create views in Snowflake under the same database that can be accessed.
Has anybody else encountered this issue and know a better solution? Is it the version of the ODBC driver for Snowflake (which I assume is the most current because the user followed a canned set of download directions created by our IT department).
Related
I have an ACCESS database that I'm using to test migration to SQL Server. It has one local table; no linked tables, forms, queries, or reports. One site said to use the open the Database Tools tab, and click the Access Database icon in the Move Data group. When I do, it tells me that the database must be split. How do I let ACCESS know that the database has been split?
The move data features up to Access 2010 ALSO had a feature to move data to SQL server. However, due to SQL server always changing and having new versions that come out at "different" times then ms-access?
the feature was deprecated, and versions of Access after 2010 don't have the move to sql server anymore.
If this is just say a simple single table, then it you can use SQL server studio to import the table. (but, you lose PK settings, and indexing, and relationships (assumes you have more then one table and related tables).
If you looking to migrate a lot of data, and a lot of tables?
Then it is high recommended that you use the Sql Server Migration Assistant for Access. (SSMAA).
It is a separate download. You can find SSMAA here:
Information on this tool, and download links can be found here:
https://learn.microsoft.com/en-us/sql/ssma/access/sql-server-migration-assistant-for-access-accesstosql?view=sql-server-ver16
While the tool has a learning curve, it is well worth the efforts for any type of serious data migration from Access to SQL server.
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 currently working on a Attendance & Payroll System. The developing appliction should be able to import the data from Finger Print Scanners.
The client already has 15 finger print machines installed at their premises and it exports to an MS Access database with the following fields
Employee ID
Date
Check-In
Check-Out
The system which we are going to develop will have a seperate MySQL Database.
How can i transfer the data in real-time from MS Access to MySQL?
Whenever a user punches their thumb it autmatically updates the MS Access database.
I want to do,
Data Migration for existing data - This is already accomplished
Transfer all real-time new data to MySQL
How can i accomplish the 2nd task?
I tried using an ODBC connector to mysql. it pulls the table from MySQL to MSAccess. I want to it other way around. ie. Pull the data from existing columns and insert it to mapped table in MySQL.
How can i do this?
You don’t need to transfer the new data.
What you do is use linked tables to MySQL so that all data resides on the MySQL server at all times.
Access is perfect able to use “linked” tables to Oracle, or SQL server or MySQL. When you use linked tables, then access functions as before, but ALL table data is live edited and is on the server – no transfer or sync is required.
I'm usually not working with Microsoft products. I have an MS Access 2007 project here, and I know that the MSSQL Server with the Database has some procedures. How can I make them visible? I can just browse trough tables and views...
Thanks and regards,
Jan Oliver
When you say access project, are using the term that you have a project you're working on, or you do specifically mean you're working with an access data project? (ADP). The ms access term ADP has an specific meaning that's very important in your context.
In ms access a good number of developers simply use ODBC linked tables to data is sitting on SQL server. There's also an option in ms access to create what is called a Access Data Project (ADP). When you choose to create an access data project then any view design services such as the relationships editor, table design etc. looks like you're developing inside of the access desktop client, but in fact behind the scenes access is sending DDL (data definition language) commands to SQL server to make those modifications on the server side object. So, you CAN modify server side objects inside of ms-access. No local tables can exist when you create a ADP.
What this means that the version of access and SQL server have to be more closely matched then if you're not using an access data project. If you open up the access database and look in the query table, you should see stored procedures appearing in the list. Access should let you modify them.
So take a look of the file extension, if this is actually an access data project, then the file extension for the access database will be *.adp.
If the file extension is mdb, or accDB, then this is not an access data project, but is a traditional access database in which linked tables to SQL server are being used. This this case of non ADP, then the views and tables you link to will only appear in the tables table. Furthermore ANY design changes you make will be done using the SQL server management tools and NOT the access client. So, changes to tables and views and procedures etc. are NOT made and CAN NOT be made inside of the access client like they can when you're using an access data project. Despite this limitation, most developers prefer using linked tables as opposed to an access data project because of the loose tie between the version of SQL server. In fact you can use even different database servers in these cases such as Oracle or MySql. The other significant advantage of linked (odbc) tables is that the linked tables allows multiple data sources from local files, server based etc. And, you also can have local tables (ADP does not allow local tables in the client).
So your ability to edit or not edit the server side objects inside of access will be determined by the above scenario IF you are in fact using a ADP or not.
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...