I have an access form with a list of numbers [1, 2, 3, 4, 5]. When a number is clicked on, i want to run a pass through query that opens a datasheet view of the query. So for example, say [3] is clicked, then a pass through query would run SQL like
select * from mytable where number=3
Do I have to use VBA for this? How is it done in VBA? I have the log in information for the SQL server, but no permissions other than querying tables.
You can send SQL queries to your SQL Server databases via ADO.
More on ADO: http://support.microsoft.com/kb/257819
See Also: Connecting to SQL Server over network using ADO from Excel VBA
The easiest way to achieve what you want to do is to create and save a Query in your database which you can call DoCmd.OpenQuery on.
The most efficient way to pull the data would be a pass-through query which has the predicate (WHERE element) set already (and all the connection properties as well). The challenge here is to pass the parameter (1-5) through to the saved pass-through query in a way you can call DoCmd.OpenQuery on it.
A way to do this would be to on the AfterUpdate event of the updated control that supplies 1-5, create a pass-through QueryDef (see here: https://support.microsoft.com/kb/112108) using dynamic SQL, making sure the WHERE clause represents the number you want to filter by. You'll need to set the Connect property of the new QueryDef object to have the connection string to your external db. Save the QueryDef you create, then call it by name with DoCmd.OpenQuery. This should provide you with the functionality you are looking for.
Something you actually need to do before you create the pass-through QueryDef is check for its existence and delete it if it already exists (or update its properties, I guess) or you will get an error.
Use a saved pass-though query and DAO.
You can do this for a total of 2 lines of code.
This code will work:
CurrentDb.QueryDefs("MyPass").SQL = "select * from mytable where number = " & Me.Number
DoCmd.OpenQuery "MyPass"
Related
We use Access 2016 as a front end and SQL Server 2008 as back end.
A user creates a new record in a form. In order to generate an autonumbered ID for this new record, I use DoCmd.RunCommand acCmdSaveRecord. When I use this command, the form moves off of that record. I need to then find the ID of the record just created. I cannot search for the largest autonumber ID because we use merge replication and different users have different ID ranges.
I tried making a DateCreated column and defaulting that column to the current date and time by using GetDate() in SQL Server, but that that makes Access give lock errors and other errors because it cannot properly read SQL Server's datetime format.
Is there a .saverecord option that doesn't move off the current record in a form? Or is there a date/time field that won't produce an error when using SQL Server backend and Access frontend?
In a nutshell, I need the autonumbered ID of the last record created in a form.
Use a Pass through query to run this SQL statement after you insert your record:
SELECT SCOPE_IDENTITY() AS ID
It will return the last created identity used in the current scope.
To get the auto number field to populate in an Access form bound to a sql server table you simply need to force the form to save the record. The act of saving the record does not and should not and will not move the form off of the record.
The code to get the auto number is thus:
If me.Dirty = True then Me.Dirty = false
Debug.print "Auto number from SQL server = " & me!id
You as a general rule cannot use SELECT SCOPE_IDENTITY() since the connection used in the form will be different then the connection you use to execute the SQL pass-through query. So the responses here are wild goose chase and incorrect and the wrong way to approach this problem.
Run another command in the same session to get the id:
SELECT ##IDENTITY
For more details check the: MSDN documentation.
Anyway, if you have an API to access the database, and it doesn't expose this, it should be expended to return the scope identity, since this is the only reliable way to know what ID was generated.
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).
I have a passthrough query to pull my "Active Members" from an Oracle database via an ODBC passthrough query. It works great, I can link to members retrieved by the query just like I would an Access table.
My question is, will this passthrough query automatically refresh itself each time I reference it? Or should I specify the update using VBA code? Essentially, each time a user searches for a member, I need my pass through query re-run.
No, there's no auto-refresh of pass-through queries, they're just queries stored in another db's syntax.
What I usually do is create a macro deleting rows from the existing table and running the pass-through query. If the macro introduces too much overhead, however, you could also code the steps in a function with VBA.
I have an Access database that i need a complete dump of into Excel to import into another data source.
Is there a way i could run a SQL query using "Get External Data" function from Excel and if so what should the query look like?
Try using Microsoft Query and access Access, http://office.microsoft.com/en-us/excel-help/use-microsoft-query-to-retrieve-external-data-HA010099664.aspx. There's an option to "View data or edit Query in Microsoft Query".
This is for a SQL database, however you can use the same principal and just change the connection string to Access. Then, you would loop through the Tables collection, and within that loop you would loop through the Fields collection using something like this.
Also, have a look here and see the syntax used to loop through the Access tables collection using ADOX from Excel.
I've wrote an SQL query in MS Access and Access made a mess of it, only to show it "graphical".
How do I stop it from doing this?
There's no stopping Access from changing your SQL if you save it as a QueryDef object (ie, using the graphical query editor). You have (at least) two other options:
Build your queries in VBA
Store your queries in a table dedicated to queries using a Memo field to store the SQL (this will also require some VBA to take the SQL and execute it or assign it to a temporary querydef, etc.)
You can still use the QBE (query-by-example) window to generate your SQL initially if you want.
Also, if you have a non-Jet backend (MS SQL Server, for example) you can write pass-through queries. You lose the graphical interface but gain all of the functionality of writing SQL in your backend of choice. Access won't rearrange the formatting on pass-through queries.
Here's a dirty trick : append an UNION at the end of the query which is always FALSE.
SELECT field_1, field_2
FROM my_table
UNION select field_1, field_2 FROM my_table WHERE False = True;
That's horrible and I'm ashamed to do something like that but it works.