July 24, 2008 07:20pm pdt

Member Login

Top Experts

Yearly

1capricorn1 2,093,351
2DatabaseMX 1,310,821
3boag2000 585,819
4LSMCons... 550,404
5peter57r 440,168
6harfang 409,203
7GRayL 386,131
8jimhorn 258,552
9matthews... 250,724
10cactus_d... 242,502
11TextReport 236,057
12hnasr 201,250
13ee_rlee 173,155
14angelIII 140,704
15jefftwilley 140,435

null

	[x] Attachment Details

CurrentDb.Execute expects a parameter but DoCmd.OpenQuery works fine.

Zones: Microsoft Access Database, SQL Query Syntax, Access Coding/Macros

When I run
DoCmd.OpenQuery "q520S1C3_b"
it works fine; but when I run
CurrentDb.Execute "q520S1C3_b", dbFailOnError + dbSeeChanges
I get this error: Run-Time Error 3061 (Too few parameters. Expected 1).

The SQL for q520S1C3_b is:
INSERT INTO t430_ECHistory ( ID, Who, What, Details, Call, [Date] )
SELECT t410_WItem.ID, t410_WItem.Who, t410_WItem.What, t410_WItem.Details, True AS Call, Date() AS [Date]
FROM t410_WItem
WHERE (((t410_WItem.ID)=[Forms]![f520_WItem]![sf520S1].[form].[ID]));

Ref: md143/ f520S1/ CalledToday_MouseDown

Start your free trial to view this solution

[x]

The Solution Rating System

With so many solutions, how can you tell which solutions are most likely to help you and which ones are not? To provide you with a tool to use, we rate our solutions based on various elements that most accurately determine if a solution is a quality solution. To explain what factors affect the solution rating, here are the elements we take into consideration when formulating our solution rating.

The Grade of the Solution
The Zone Rank of the Expert Providing the Solution
The Number of Author and Expert Comments
The Number of Experts Contributing
The Feedback of the Community

Your Input Matters
Because of the way the system is set up, the most important variable in this equation is you. As a member of Experts Exchange, you are able to cast your vote on the quality of the solutions in regard to how complete, accurate, helpful and easy to understand each solution is. When you provide your feedback, each rating is adjusted accordingly. So, if you see a solution that has a poor rating that you think is a good solution, let us know by rating it. As you do, the rating will be adjusted and will become more accurate for other members of our site.

If you have any suggestions that you would like to make for our rating system, please ask a question in the Suggestions Zone of Community Support.

Thank you!

8.8

Question Stats

Zone: Microsoft

Question Asked By: Milewskp

Solution Provided By: mbizup

Participating Experts: 4

Solution Grade: A

Translate:

Loading Advertisement...

Open Discussion

null

Comment by DatabaseMX

"Following the lead from mbizup, also try:"

Ahhh ... don't you think mzip should have gotten some credit here ??

mx

null

Comment by Milewskp

Yes, thanks for pointing this out.
Although I like eghtebas's solution better (less complicated), mbizup did answer the question first. I will ask moderator to split points.

null

Comment by DatabaseMX

Excellent.

thx.mx

null

Comment by mbizup

Thanks, folks.
That was a really nice gesture from all of you.

null

Comment by DatabaseMX

btw ... what I posted here:

"You cannot use the name of a stored query as you can in DoCmd.OpenQuery"

is wrong! In fact, you can. I was thinking of something else.

mx

null

Comment by mbizup

Joe,

I'd missed this before:
>I don't see what 'You may need to retrieve the Control's value seperately.' has to do with anything.

References to form controls work fine in stored queries. If you take that same query and open it through VBA, the same form reference that worked before will cause an error -- unless you evaluate that reference seperately. This holds true for OpenRecordset statements, and also CurrentDB.Execute and Docmd.RunSQL.

Docmd.OpenQuery is the VBA equivalent of opening the query directly through the database window, and the form references work fine using that method.

null

Comment by DatabaseMX

Well, just ignore my entire post. I was clearly thinking of something else. I do that all the time, but ... I use a Collection to store (Set) the form reference first, the the query calls a function which retrieves (Gets) the value. That way, I can store many different values for various cases in on Collection. That's why at first I was thinking ' Huh, I do that all the time!" ... but not quite.

mx

null

Comment by Vee_Mod

I gave up that 'thinking' stuff a long time ago - much more fun that way.

/unsub

null

Comment by DatabaseMX

mzip ... you can also user the Parameters Collection of thw QueryDef object to reference the form object (text box,etc). I'm trying to get an example now ...

mx

null

Comment by DatabaseMX

ok ... here is the example.

Setup:
A form with RecordSource of tblEmp (employees table - two fields EmpID, EmpName)
Textbox on the form bound to EmpID
A saved Query Def (qryParametersTest) in the database window with this SQL:

SELECT tblEmp.EmpID, tblEmp.EmpName
FROM tblEmp
WHERE (((tblEmp.EmpID)=[Forms]![frmTest].[txtEmpID]));

This function:

Public Function mQyrParmTest() As Boolean

Dim rst As DAO.Recordset, qdf As DAO.QueryDef
Set qdf = CurrentDb.QueryDefs("qryParametersTest")
With qdf
.Parameters("[Forms]![frmTest].[txtEmpID]") = ([Forms]![frmTest].[txtEmpID])
' or Parameters(0) = ([Forms]![frmTest].[txtEmpID])
Set rst = .OpenRecordset(dbOpenDynaset)
MsgBox rst![EmpName] 'this will display the Employee name related to the ID currently on the form
End With
Set rst = Nothing
Set qdf = Nothing
End Function

------

Open the form and navigate to some EmpID showing in the text box, then call the function from the vba immediate window. The message box will display the employee name associated with the ID in the form text box.

Note that wherein I use Form. instead of Form! almost everywhere, this is one place where the bang symbol (!) is necessary.

20080723-EE-VQP-34 / EE_QW_EXPERT_20070906