Connect to ODBC from Access (Newbie) - ms-access

I am spreading my wings into ODBC but need a kick-start. I have the SQL for the query and have ODBC installed (it works in Excel; that's how I got the SQL for the query). I need to know how to connect to the database from Access and pull the data into my table. Can someone please help with that?
Thank you,
Dave

Do you wish to use Excel data in Access? If so, simply link the spreadsheet (External Data).
EDIT
You can also link tables from other Access databases to easily create queries in the Query Design Window.
DAO is native for Access, here are a few notes:
Dim db As Database
Dim rs As DAO.Recordset
Set db = OpenCurrentDatabase("c:\docs\MyDb.mdb")
Set rs= db.OpenRecordset("Select Field From Table")
db.Execute "Update Table Set Field=2", dbFailOnError

I don't have MSAccess installed on this machine, so I might have the menu names incorrect.
If I understand correctly you're just trying to get MSAccess to connect to an ODBC database.
Go to the Main menu. Select "File"/"External Data"/"Link" ...
A wizard will step you through the connection set-up and show you the tables available in the database you're connecting to.
Once you've selected all the tables you want to work with, Access imports the definitions and they behave mostly like the local tables.
also see
http://www.aspfree.com/c/a/Microsoft-Access/Importing-Data-into-MS-Access-with-ODBC/1/

Related

ODBC Driver Connect auto fill

I have an Access Database connected(linked table) to an Oracle database.
I wrote some Select queries. Everytime I run it, I get an "Oracle ODBC Driver Connect" input box.
Is there way to write a vba macro to enter username and password (auto fill) and Enter Ok.
Trying to set up an auto run for macros in this Access db.
Any help is appreciated.
As pointed out, when you link the tables, you are given an option to save the password in those table links. If you missed this step, then you will get that ODBC prompt.
THIS HAS ZERO to do with you writing select queries. The simple matter is try clicking on one of the linked tables you use in such quires. Either you get an ODBC prompt or you do not.
If you do, then of course you going to get such a prompt when you write a query. YOU WANT to FIRST get the table links working without an ODBC prompt and THEN write those queries based on the linked tables.
So get the linked tables working first. Forget about and don’t’ worry about your queries you are writing. Until such time that a simple click on (opening) a linked table works and does not throw out the ODBC prompt, then you are looking at the WRONG problem.
Once you get your linked tables working without a prompt, then your queries will also work without a prompt.
So you have two choices to fix this problem.
Simple re-link your tables, and ensure that you select [x] check box during re-link to save the password.
The prompt you missed and want to select is this one:
Now if your tables are already linked and you run the linked table manger, you WILL NOT get this prompt anymore. So you have to delete the table links, and re-create.
Of course deleting the table links can often result in the linked table names being changed, and that can be a pain, especially if you have a LOT of linked tables. Only you can make this judgement call as to what is less work. If you have just a few tables, then just delete them, and use the external data -> then in the import and link secton, choose ODBC and you can add the tables, but REMEMBER to select (check) the above save password box as per above that you missed.
Now, most people over time wind up with some table re-link code VBA. So if you have suc re-link code already working and handy, then simply re-run that code with the user/password included in the connection string you use in that code. Of course if you don't have such code, then the above linked table manager in Access is a code free solution and is obviously your best choice and course of action.
So in place of above, you can find some table re-link code that will force (save) the user/id in the table links for you.
However, if you don’t want to delete + re-create all those tables, and you don’t have already setup some re-link code, there is also another (3rd) choice.
In your application start-up code simple execute a one-time logon. If you do this, then the ODBC prompt will not appear when you use the linked tables and hence also not appear when you attempt to run/build/use a query based on those linked tables.
The code to execute a one-time logon will look like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
Above code run ONE time on start-up of your application will thus eliminate the ODBC prompt(s) when you click on a linked table. And of course once that issue of linked tables is resolved, then of course creating or clicking on your query or running those quires will now ALSO work without the prompts.
You can NOT auto fill that prompt, you have to take CORRECT steps in the first place to PREVENT that prompt from appearing. So to answer your question?
No, you can't write code to enter the requested prompt, but if you link your tables with the password saved, or execute the above logon code, the prompt will NOT appear in the first place.

calling oracle stored procedure in ms access without saving password in pass through query

I am working on MS ACCESS 2003, i need to call oracle stored procedure through ms access. I am using pass through query to call the procedure. I have created user DSN with Microsoft driver for ODBC and successfully able to call the procedure.
ODBC;DSN=DSN_NAME;UID=USER_NAME;PWD=*******;DBQ=MY_SERVER
But my worry is to save the password in pass through query, some times password changes then i have to change the connection string for that pass through query every time.
Is there any other way to calling the procedure via pass through query without changing the connection string when password gets change or is there any code in vba to doing the same. I am looking for dynamic way where calling procedure would be easy without changing password to each and every pass through query by going to its properties.
Thanks !!
Yes this is possible however you need to know or in other words be able to retrieve the password somehow within your application. In a production line application you would use the user(login) password to create a connection string to access the back-end tables.
The structure would look similar to this:
Create a module to host connection related public functions.
Create new function GET_CONNECTION_STRING() as String: Which will return your connection-string including logged in user's password.
loop through the table definitions/ query definitions in your database and update the .connect property.
In most cases you would change the .connect property and use the .RefreshLink to refresh/connect manually.
You need to add a new reference to use DAO object. (Microsoft dao objets, or activex data obects or ado objects whichever type you want to use)
some startup code:
dim db as dao.database
set db = currentdb
dim tdf as dao.tabledef
For Each tdf In db.TableDefs
If tdf.connect <> vbNullString Then
tdf.connect = GET_CONNECTION_STRING & ";TABLE=" & tdf.name
'if you want to manually refresh uncomment below line
'tdf.refreshlink
End If
End If
Next tdf
adding above function to a startup macro will ensure all the linked tables (queries you need to perform extra) are updated with the newest connectionstring.
try and post your code when you are stuck.
Any linked table(s) and that of including “saved” pass-though quires in Access does NOT require the password to be included in that string. If you leave out the password, then a SINGLE logon to the Oracle database will THEN allow ALL linked tables and pass though quires to run and do so without a password.
The first step is to setup your tables as DSN less, and DON’T include the password (you likely best to delete existing linked tables).
To link using above but NOT include pass-word means you FIRST will have to execute a logon into the database. Once done, then you can link your tables and pass-though quires. So a one time link of tables as DSN less and you are off to the races.
Once above is done, then any and all connections (including pass-though query) will all work and work without having to include the user name.
The above thus means you don’t have to re-link for different users logging into the database.
To run a pass-through query, you can then use this one line of VBA code:
CurrentDb.Execute.QueryDefs("MyPassQuery").execute
How to link with DNS-less is outlined here:
http://www.accessmvp.com/djsteele/DSNLessLinks.html
How to “cache” the user logon, and NOT require user + logon in the linked connections or ones used for pass-though is outlined here:
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
So you can on startup execute the logon one time, or prompt the user for a logon, and from that point on your application and pass-=though queries will run without required a password. And this ALSO means you can have different users logon and NOT have to re-linked the existing tables (and pass-though quires).

Access: notify when linked table source changes structure?

I have imported a table in Access 2007 through Oracle ODBC. My problem is that sometimes the tables change structure in Oracle (eg new columns are added) and when that happens Access doesn't automatically pick up the changes in its linked table.
Instead it keeps using the old structure and even worse some rows simply won't show up in the Access queries (I don't know why?).
The other problem is that I don't have any control over the Oracle DB so the changes can happen any time. Manually updating the linked tables all the time is too much of a hassle. Is it possible to somehow set Access up to notify me of the changes? I mean, somehow Access must be able to tell that something has changed - the question is; can it tell me?
Regards,
John
Run this function - you can either link it to a form Open event, or just run it when you need to refresh the data
Sub relinkTables()
Dim tdf As DAO.TableDef
For Each tdf In CurrentDb.TableDefs
' check if table is a linked table
If Len(tdf.Connect) > 0 Then
tdf.Connect = "your odbc connection string to the DSN or database"
tdf.RefreshLink
End If
Next
End Sub

How to end Windows lock on file in ODBC connection?

I am using Access to import data from a series of SQLite 3 databases that are all structured the same. I have a system/user DSN for "Import.db". My Access DB has linked tables to those in Import.db.
My goal is to import the data via the linked tables into Access tables, then delete Import.db, then copy the next SQLite3 DB to the same location and call it Import.db, and then keep repeating the process till all are imported.
I took this approach because I don't know how to create DSNs on the fly and link tables for SQLite3 dbs. SQL Server, yes, but not SQLite3. So I thought, just use the same DSN but change the actual file.
The trouble is, after opening my Access DB and opening the linked tables, Access creates a Windows file lock on Import.db. So I can't delete and replace it. Instead, I can import one, then close Access, reopen Access, and repeat. Not so hot.
Suggestions?
You can get the connection string of a linked table with:
Debug.Print CurrentDb.TableDefs("MyLinkedTable").Connect
You now have the information you need to create a query that imports without a linked table.
You might get something like this:
ODBC;DSN=SQLite3;Database=Z:\Docs\Import.db;StepAPI=0;SyncPragma=NORMAL;
NoTXN=0;Timeout=;ShortNames=0;LongNames=0;NoCreat=0;NoWCHAR=0;
FKSupport=0;JournalMode=;OEMCP=0;LoadExt=;BigInt=0;
But you probably won't need most of it, so:
sODBC = "[ODBC;DSN=SQLite3;Database=Z:\Docs\Import.db;]"
''Create table query, but append and update are also easy enough
sSQL = "SELECT * INTO SQLite_Import FROM " & sODBC & ".SQLiteTableNameHere"
CurrentDb.Execute sSQL, dbFailOnError

Access 2007 SCM over multiple databases

I'm looking for a way to implement SCM over multiple Access 07 databases. We just need source control for the forms/code.
Essentially we have 100+ databases that are structured the same, use the same code/modules, but each contains data for just one client. When we make a code change we currently have to manually go through each file to make the change.
Has anyone implemented source control for something similar(God help you if so) or have any ideas?
PS - I realize there is lots of DailyWTFery in here, this is a legacy product I've been assigned to do some emergency maintenance on before we rewrite to .NET/MSSQL, but I think there's enough work to warrant putting this in place if it's possible.
You can find out more how to do SCM in this question; it does involve exporting and importing the code and forms using some undocumented (or poorly documented) commands. I also recall issues with checksums or version numbers happening when you used that method.
However, you could solve a lot of this problem by separating the the data and the application sides of the DB into separate files and then adding table links to the data DB from the application DB. Then you would have just one Application DB, and oodles of Client data DBs.
Switching to a different client is as simple as re-linking to the other DB.
You can do that manually or code it with a structure something like this:
Dim myTable As TableDef
Dim db As Database
dim strDBPath as string
strDBPath = ";DATABASE=C:\workbench\MyNewDB.mdb"
Set db = CurrentDb
db.TableDefs.Refresh
For Each myTable In db.TableDefs
If Len(myTable.Connect) > 0 Then
myTable.Connect = strDBPath
myTable.RefreshLink
End If
Next
'' Note: This whips through every table in your database and re-links it to the new
'' DB. ODBC links will have a different value for strDBPath - I'll leave that as
'' and exercise for the reader