I've been writing MS Access apps for a long time. I just switched to Access 2010 and now wherever I open a form in which I'm creating the InputParameters in code, the app prompts me to enter the parameters. I'm baffled and can't figure this out.
The following code has worked on all previous versions of MS Access until Access 2010:
Dim strRS As String
Dim lngID as Long
Dim intSomethignElse as Integer
strRS = "dbo.StoredProcedureName"
lngID = 1
intSomethignElse = 2
Forms!SomeFormName.InputParameters = "#parameter1 = " & lngID & ", #parameter2 = " & intSomethignElse
'Verify the parameters do indeed exist and they do:
Debug.Print Forms!SomeFormName.InputParameters
Forms!SomeFormName.RecordSource = strRS
Now when the form loads I get prompted to enter #parameter1 and #parameter2.
How do I get this to work again in MS Access 2010?
Any help is appreciated.
I had the similar VBA code. It worked fine in Access 2010 until recently and I got the same issue as the pop up window asking for parameters.
After I change the code to simliar to
Forms!SomeFormName.RecordSource = "exec dbo.StoredProcedureName #parameter=" & lngID
as Remou suggested in the comments, my application works again.
May be the RecordSource is not empty. Make sure it is empty in design view.
EDIT:
msdn says: The stored procedure should be executed using a command string containing the {call } syntax with one ? marker for each non-default parameter in the InputParameters list.
I do not know the call syntax, but I would try something like this:
strRS = "exec dbo.StoredProcedureName ?, ?"
Related
We've recently upgraded some PCs and have subsequently come across some issues with the VBA code in an Access frontend we use to perform operations on a MySQL database. The specific piece of code pulls a serial number from the database and then prints it to a Dymo Labelwriter 450 as a barcode.
Style = vbExclamation + vbYesNo
Title = "Print Label For " & Me.txt_Barcode & " ?"
Response = MsgBox("Do you want to print a label for serial number " & Me.txt_Barcode, Style, Title)
If Response = vbYes Then
Dim myDymo As Object
Dim myLabel As Object
'On Error Resume Next
Set myDymo = CreateObject("Dymo.DymoAddIn") '
Set myLabel = CreateObject("Dymo.DymoLabels")
If (myDymo Is Nothing) Or (myLabel Is Nothing) Then
MsgBox "Unable to create OLE objects"
Exit Sub
End If
The code now breaks at line 8, i.e.
Set myDymo = CreateObject("Dymo.DymoAddIn") '
The error code I was getting was relating to ActiveX (which seemed possible that it might relate to going from 32-bit to 64-bit), but since installing the latest DLS from Dymo (DLS8Setup.8.2.2.996), it seems to have evolved to the following:
Run-time error '-2147467261 (80004003)
Automation error
Invalid pointer
I'm hoping someone can point me to an easy fix so I don't have to totally re-write the code!
Thanks in advance!
I managed to resolve this one in a couple of steps and to be honest, I'm not sure which exactly fixed this specific part of the problem:
First was to run the DYMO_Label_v.8_SDK_Installer
I also switched from the latest Dymo Connect to DYMO Label v.8
I then had to ensure the Barcode font we're using was installed as an admin for all users, rather than just a specific user profile
and finally, and I think this may have been the kicker, the software was looking for a label template called 'Serial.label' which I found on our server and copied and pasted into the C: drive where the software was looking for it.
I'm just glad I didn't have to re-write the code!
I have this qry in access, if I go into its design it has a criteria (which as I understand it is a parameter).
The Report this qry is based off of works great, click on it a little thing pops up asks the required info and off it goes. In code I am trying to do this and get a
Run-time error '424'
Object Required
the offending line:
qdf.Parameters("Insurance Name").Value = inputStr
Lines before it:
Set qfd = CurrentDb.QueryDefs("qryInsGrpRoster")
Dim inputStr As String
inputStr = InputBox("Enter Insurance")
'Supply the parameter value
qdf.Parameters("Insurance Name").Value = inputStr
inputStr definitely equals the value, it fails though.
The criteria line in the qry is:
Like "*" & [Insurance Name] & "*"
Do I need the likes and all that to set that parameter?
in Access 2010 and 2013
This uses DAO and might be of interest
DIM MyQryDef as querydef
Dim a as string
a = ""
a = a & "PARAMETERS Parameter1 INT, Parameter2 INT; "
a = a & "SELECT f1, f2 FROM atable WHERE "
a = a & "f3 = [Parameter1] AND f4 = [Parameter2] "
a = a & ";"
Set MyQryDef = currentdb().CreateQueryDef("MyQueryName", a)
MyQryDef.Parameters("Parameter1").Value = 33
MyQryDef.Parameters("Parameter2").Value = 2
' You could now use MyQryDef with DAO recordsets
' to use it with any of OpenQuery, BrowseTo , OpenForm, OpenQuery, OpenReport, or RunDataMacro
DoCmd.SetParameter "Parameter1", 33
DoCmd.SetParameter "Parameter2", 2
DoCmd.Form YourFormName
' or
DoCmd.SetParameter "Parameter1", 33
DoCmd.SetParameter "Parameter2", 2
DoCmd.OpenQuery MyQryDef.Name
See here:
https://msdn.microsoft.com/en-us/library/office/ff194182(v=office.14).aspx
Harvey
The parameters property of an Access Query is read only.
You have basically two options here that I can think of right off.
The first is to just completely rewrite the SQL of the saved query each time you need to use it. You can see an example of this here: How to change querydef sql programmatically in MS Access
The second option is to manually set the RecordSource of the report each time it opens. Using this method you will not use a saved query at all. You'll need to set/store the entire SQL statement in your code when the report opens, ask for any input from the user and append the input you get to your SQL statement. You could setup a system where the base SQL is stored in a table instead but, for simplicity, that's not necessary to achieve what you're trying to do here.
MS Access does allow you to use parametrized queries in the manner you're attempting here (not the same code you have), but as far as I know, it would require you to use Stored Procedures in MS SQL Server or MySQL and then you'd need to use ADO. One big downside is that Access reports cannot be bound to ADO recordsets so this isn't really an option for what you're trying to do in this particular instance.
Seems like a typo. You're creating the object named 'qfd', and trying to use the object named 'qdf'
Set qfd = ...
and then
qdf.Para...
I like to put Option Explicit in my modules to help me find these types of issues.
I am building a system using Microsoft Access 2013 that uses MySQL as a backend. I am trying to figure out a way to do some kind of basic user management, ideally in such a way that users would have to "log in" when they launch the database, and then their username would be easily accessible by the system while they are using it. I've tried searching for solutions, but most of them just tell me to use Office 365 or sharepoint, which are not options at the moment. Does anyone have an idea of how to accomplish this? Thanks in advance!
I recommend building your own user storage and login system. You'll basically need to create your own users table (in MySQL in your case), make forms to manage users, make a Login form, and write code to control the login process.
Logging in usually consists of checking some kind of credentials they type in against existing data in your users table. You can usually do this in Access with DLookup or DCount statements but I usually end up using a DAO or ADO recordset instead since I like to pull out more than one value from the User's table and I also like to write things back to it right away, like the LastLogin datetime, LastLogin computername, etc.
I actually wrote an example database which you can download here. It needs a rewrite. I've changed quite a few of my practices since Jan, 2011. But give me another year and it would need another rewrite.
I usually program the login form so that the user enters their initials and then a password. If you go this route you need to have a unique index setup on the Initials field to prevent duplicates. If you're going to have a lot of users you need to use a Username instead, which could still theoretically be the users initials.
Here's what my code would look like to authenticate a user. Be aware that this is far from truly secure. This assumes that passwords are stored in plain text. Users could theoretically try to do SQL Inject from here because I'm not use a parametrized query or stripping out special characters from their input such as # or ;.
Private Function AuthenticateUser() As Boolean
Dim sInitials As String
Dim sPassword As String
sInitials = Trim(Nz(Me.txtInitials, ""))
sPassword = Trim(Nz(Me.txtPassword, ""))
If sInitials = "" Or sPassword = "" Then
'Logging in with blank passwords is not allowed
AuthenticateUser = False
Exit Function
End If
If DCount("EmployeeID", "tblEmployees", "[Initials] = '" & Replace(sInitials, "'", "''") & "' AND Password = '" & Replace(sPassword, "'", "''") & "'", True) = 0 Then
MsgBox "Invalid Credentials."
AuthenticateUser = False
Exit Function
Else
Dim rs As New DAO.Recordset
Dim sSQL As String
sSQL = "SELECT * FROM tblEmployees WHERE initials = '" & Replace(sInitials, "'", "''") & "'"
Set rs = CurrentDb.OpenRecordset(sSQL)
If Not (rs.EOF And rs.BOF) Then
'Config is an instance of a User Defined Type. It could also be a class object.
Config.UserInitials = rs("Initials")
Config.UserFullName = rs("EmployeeName")
Config.UserID = rs("EmployeeID")
rs.Edit
rs("LastLoginDateTime") = Now()
rs("LastLoginComputer") = "Function Required to Get Computer Name"
rs("ProgVersion") = "Your Program Version Number"
rs("CurrentDbPath") = Left(CurrentProject.path & "\" & CurrentProject.Name, 254)
rs.Update
End If
rs.Close
Set rs = Nothing
AuthenticateUser = True
End If
End Function
In my applications I use a global object, in this case an instance of a User Defined Type, which I call Config. I store any kind of application runtime related settings in there for the duration of the runtime of the application. Of course this object gets destroyed when the user closes out of the application or when a code reset happens (which cannot happen in Access runtime, but does happen frequently during development). You could use a class object instead of a User Defined Type. Or you could use individual global variables for everything, which I don't recommend (that's what I used to do). A User Defined Type simply allows you to group global variables together and gives you an easy way to refer to them in your code during design time by typing in Config., which then brings up every option using Intellisense (assuming you have it enabled).
If you want your settings to survive a code reset, you need to use TempVars. TempVars became available with Access 2007. I do not use them now (contrary to my example database) because they are not strongly typed. There's no Intellisense to help you get the correct TempVar and you can technically refer to a TempVar that doesn't even exist and Access won't throw an error. I think TempVars is really just a Dictionary object with all of it's shortcomings, and the single benefit of surviving a code reset. I can imagine storing a Connection String in there, but I wonder if it's worth using TempVars for anything at all. If a code reset happens, my entire application needs to be reloaded anyway since I setup a lot of global objects and variables when the application first opens and the user first logs in.
FYI, in previous versions of Access there was user security built in. I think Microsoft discontinued that starting in 2007. I never really used it so I didn't miss it when it got discontinued.
I had a form with some VB code that was using Access 2003. Recently we wanted to use the same form as a small front end interface for another database that has a SQL Server backend. However, the file type for this project in Access is .adp and not all of the vb code is working properly. If you could help me fix the bugs in this code:
Private Sub SurveyNameCombo_AfterUpdate()
Dim db_CFC As DAO.Database
Set db_CFC = CurrentDb
Dim rst As DAO.Recordset, query As String, count As Integer
query = "SELECT DISTINCT SurveyID FROM tbl_SurveyMeta WHERE SurveyName = " & Chr(34) & Me.SurveyNameCombo.Value & Chr(34)
Set rst = db_CFC.OpenRecordset(query)
count = rst.RecordCount
If count > 1 Then
Me.SurveyIDCombo.RowSource = query
Else
rst.MoveFirst
Me.SurveyIDCombo.Value = rst.Fields(0).Value
Call SurveyIDCombo_AfterUpdate
End If
End Sub
It is throwing errors in the for the DAO.Database and DAO.Recordset.
Thank you for your help!
The error message "User-defined type not defined" on a line such as this ...
Dim db_CFC As DAO.Database
... means your application doesn't include a reference to the Microsoft DAO Object Library.
Open a code module, then check from the main menu in the VBE editor: Tools->References
Ordinarily the cure would be to place a check mark in the box next to Microsoft DAO Object Library, then click OK. However, your application is an ADP, and I don't know whether DAO can even be used in ADP. You can try. :-)
Sorry I can't tell you more. I quit using ADP a few years ago. Instead I use the MDB format with ODBC links to SQL Server database objects. Perhaps you could consider the same approach if you're unable to get the ADP version working as you need.
I'm writing an MS Outlook (2003) macro which uses an ADO Connection to an Access DB (2003). I am opening a connection, getting some records into a Recordset, which I use to populate a grid (but not bind to). I then close the Recordset and Connection and set both to Nothing.
The process creates an instance of MSACCESS.EXE, and a .ldb file for the Access DB, both of which remain after I have closed the Connection, Recordset, Macro and Outlook itself. One or both of these remnants is preventing opening the Access DB until the MSACCESS.EXE process is manually killed and the .ldb file is deleted.
Similar posts say "close the connection" but that is not solving the problem.
Here's the VBA code:
Screen.MousePointer = vbHourglass
Set db = New ADODB.Connection 'Declared at module level
Set rs = New ADODB.Recordset 'Declared at module level
Dim sSQL As String
sSQL = "SELECT Customers.ContactFirstName As Name, Customers.ContactLastName As Surname, Customers.EmailName AS Email, Customers.Address, Customers.Area, Customers.Town FROM qryCustomersWithEmail ORDER BY Customers.ContactLastName ASC"
db.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & "C:\My Documents\Tables.mdb;Persist Security Info=False"
rs.Open sSQL, db, adOpenStatic, adLockReadOnly
If rs.RecordCount > 0 Then
'actions performed on recordset removed
End If
rs.Close
db.Close
Set rs = Nothing
Set db = Nothing
Screen.MousePointer = vbDefault
It's on Vista.
I'm doing this to provide my customer with an easy way to send bulk emails to everyone in his Access database. I tried by accessing Outlook from Access but the security "feature" of Outlook, which pops up a warning message for every email created, scuppered this approach.
UPDATE.
I removed PopulateFlexGrid and the problem still occurred just for opening and closing the recordset. What I previously omitted from this sample, as I considered it irrelevant is that I wrapped the code with Screen.MousePointer = vbHourglass at the start and Screen.MousePointer = vbDefault at the end. I removed this and the problem no longer occurs. Stepping through I see MSACCESS.EXE start up in TM when I call Screen.MousePointer = vbHourglass.
I also tried a version where I used DAO instead of ADO, no other difference, and it works without creating .ldb or starting up an MSACCESS.exe. This works with the Screen.Mousepointer code in there.
Can anybody explain this?
The answer to this is that the reference to
Screen.MousePointer
which i'd omitted as irrelevant, is actually a member of Access. Hence when i call it MSACCESS starts up.
I should have used
Me.MousePointer = fmMousePointerHourGlass
So it's my fault for copying some code from Access VBA to Outlook VBA and expecting it to work the same. Apologies to all of you who spent time looking at this!
What is the code of the function PopulateFlexGrid? Is it possible this is not closing the recordset passed to it?
Try removing this line and instead just looping through the code without doing anything and seeing if it still leaves the LDB. If it still leaves the LDB then the problem is not with the PopulateFlexGrid function
I agree with david saying there is something unclear here. Such a code cannot create an instance of Access or an .ldb file. This code could even run without Access being installed on the machine.
Could you open your recordset with a clientSide cursor? Using a serverSide cursor might cause the access file to be modified (not sure ...) in a way or another. To make sure that your next command does not interfeer in a way or another with access, you could even copy your record locally (to an xml file), close both records and connection, reopen the recordset with the xml file as datasource, and then populate your flexgrid.
By the way, and though it has nothing to do with your problem, it is usually preferable to split the object declaration to:
dim myObect as ADODB....
set myObject = New ADODB....