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...
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 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).
I have an application that creates an Jet database at run-time, and imports ~100k records so that I can make use of the indexing for performance reasons (1 minute versus nearly 10 when not using a Jet database).
The database is created using ADO Extensibility in Excel, and everything works just fine. However, my issue comes whenever I then open the MDB file in Access front-end, it automatically starts to "repair" the database.
The data is still fine after the "repair", however my main output query can not then be viewed in Access as it tells me it cannot represent the joins, and if I then view it in SQL the required joins are not there, and the query can no longer run. This still happens if I let it get "repaired" but do not open that query, i.e. it is the "repair" that breaks the query, not the act of trying to view it in Access. The funny thing about this is that I used the Access GUI query designer to construct the SQL as my life is too short to worry about it's crazy bracketing style, but it then later decides that it's too complex for itself??
Also, nothing else appears to be affected so I can only assume it's this one query it doesn't like.
This isn't a deal-breaker for me as my fix is to make the MDB hidden and advise users who can see it not to open it.
However, I would really like it if the database could be opened and I didn't have to hide it away like that. Therefore, my question is whether there is any way to prevent the MDB being "repaired" automatically?
Thanks!
Microsoft Access is "repairing" the file when opened because it is missing some tables that are specific to the Microsoft Access user interface. Since you created the MDB file directly using OLEDB with Microsoft.ACE.OLEDB.12.0, these tables are not present, and must be created when Access opens the MDB the first time. There are several ways you can circumvent this:
1) Name the MDB something other than .mdb - e.g.: MyAccessDatabase.mad - this will prevent Windows from using Microsoft Access to open the file.
2) Use COM+ to open an instance of Microsoft Access, and have it create the .MDB file. This .MDB file will then have all the necessary tables present and will not need to repair the file.
FYI, whenever Microsoft Access opens an MDB that needs repairing in this fashion, it will inspect all the QueryDef objects for invalid SQL and correct them as necessary. This is why your "complex" query is breaking.
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.
We use a product called SalesOutlook which is a type of CRM system. I need to export data from this using SSIS or some other program.
When you install the program, it creates a DSN on my system called SalesOutlookReports. It use the Microsoft Access Driver (*.mdb).
When I try to look at it using Crystal Reports I see a list of tables like:
SchemaAccount Contacts
SchemaAccount Profiles
SchemaNotes
And then under that is another folder called Synonyms and it contains
Account Contacts
Account Profiles
Notes
If I open the synonyms, I get my data, if I open the schema tables I get the meta data about the table.
My question is this. How can I easily import information from the tables I need into SQL Server for manipulation? How can I designate the synonyms instead of the "tables" so I can import the data? I cannot find a way to do it using the import/export wizard with SQL Server nor in SSIS. Perhaps I could use a linked server from SSMS?
ODBC connection in SSIS Data Flow Task should do the trick. Place a Data Flow task and then inside that you can select an ADO.NET data source. You can connect to an ODBC connection using that datasource. Select your MS Access database and voila you have a source. You can add derived columns if you need to adjust the data type and finally connect it to an OLEDB destination, which would be SQL Server.