MS Access 2010 query using tempvar inside IN() condition - ms-access

I am trying to filter a query using a temporary variable that is inside an IN() condition. The temporary variable contains a list of text values. I am using the macro-builder tool in Access 2010.
Assume I have a query qryMain that produces:
Field1 Field2
1 A
4 B
2 C
3 D
without a WHERE clause. Using the clause
WHERE [tblMain].[Field2] IN([TempVars]![tmpField2])
to filter the query, the desired results are
Field1 Field2
1 A
4 B
when tmpField2 is set to "A,B". I set tmpField2 using an on-click event in form frmMain using SetTempVar and Requery the subform/subreport object sfrmMain that is based on qryMain. This is done via the MS macro-builder, not VBA.
Unfortunately, requerying sfrmMain produces an empty table rather than the expected results. Note that if I set tmpField2 to "A", then the requery macro works as expected.
I have tried multiple variations of initializing tmpField2, based on Access's double quote requirements, but still no success. My question is similar to this as-yet unanswered question, but my question involves passing the temp variable inside an IN() statement within the WHERE clause, without using VBA.

The problem is not actually due to TempVars. If your value list came from a form's text box instead of TempVars, the result would be the same.
For what you're attempting to do, IN () requires a hard-coded list of values:
SELECT m.Field1, m.Field2
FROM tblMain AS m
WHERE m.Field2 IN ('A','B');
But, instead of a hard-coded list of values, you want to supply the list dynamically when the query is run:
WHERE m.Field2 IN (something_dynamic);
Unfortunately, Access will not cooperate. Whatever you supply for something_dynamic, Access will interpret it to be only one value ... not a list of values. And it doesn't matter what method you use to supply something_dynamic ... a TempVar, a text box, a formal query parameter, a custom VBA function which returns a string containing a list of values ... that list will be evaluated as only a single value.
If you were willing to use VBA, you could write the query at runtime to include a hard-coded value list before executing it. Since you want to avoid VBA, you can try something like this ...
WHERE InStr(1, [TempVars]![tmpField2], "'" & m.Field2 & "'") > 0
Note that approach requires quoting text values within tmpField2: 'A','B'
Also beware that approach could be painfully slow with a large table. Access would need to evaluate that InStr expression for every row in the table.

Related

Comparing multiple fields in two datasets to return a 3rd value

I am in report builder and I have my primary dataset that is from a SQL database, I also then created a second dataset (enter data). I need to compare 2 fields from each dataset to retrieve the correct value from the 2nd dataset and populate a column on my report. I have tried the IIF statements and Lookup statements but I keep getting the error "report item expressions can only refer to fields within the current dataset".
I have a attached a screenshot of what I am trying to do....
The IIF statement I tried to use.. If Acctnum and prodid = each other return IncodeNumber
=IIF((Fields!AcctNum.Value=Fields!AcctNum.Value, "IncodeAccount") AND
(Fields!ProdId.Value =Fields!ProdId.Value, "IncodeAccount")),(Fields!IncodeNumber.Value, "IncodeAccount"),"True")
See code in my problem.
You need to use LOOKUP(). The problem with LOOKUP() is that is can only compare a single value from each dataset. However, we can easily get around this issue by concatenating the two values you need to compare.
Note: This assumes the expression will be in a tablix that is bound to your first dataset and that IncodeAccount is your second dataset - the values you want to lookup. If this is not the case just adjust the expression accordingly
So for you, you probably need to do something like this..
=LOOKUP(
Fields!AcctNum.Value & "||" & Fields!ProdId.Value,
Fields!AcctNum.Value & "||" & Fields!ProdId.Value,
Fields!IncodeNumber.Value,
"IncodeAccount"
)
I've used two pipe symbols to join the values to avoid incorrect matches being found. e.g. Account 123 and product ID 4567 would incorrectly match to Account 1234 and product ID 567 as they would both be 1234567 when joined. By using the || the match would be 123||4567 and 1234||567 respectively.
You may need to convert the values to string using CStr()
Alternative approach
If you are going to do this 'join' multiple times in the same dataset then you could add a calculated column to the dataset that concatenates the two columns. Then you can use this single field in the lookup which will make things a little simpler.
Or, you could do this concatenation in a database view which would make things even easier.

What is the SSRS Multi Value Data Type and how to use

I have a multi-select.
I think the underlying datatype is int || array(int). This is pretty frustrating that you have to do a check to see if a multi-value is present before jumping into an index. But how does this value get passed to SQL?
It's easy enough to use in a IN (#variable) statement. How else can it be used? Is it a string or a table. From my investigations it appears to be single table row with many un-named columns but I'm not really sure.
Finally, when you want to simulate a multi-select in a query inside visual studio, for example to "Refresh Fields" how do you do that? For example "1,2,3", {1,2,3} or #{1,2,3}. It's not (123) because that is -123.
It dpends what you are trying to do and in what context.
As you said, if you have a datset query that is a SQL script (as opposed to a stored proc) then you can use IN(#paramName). In this instance SSRS take the parameter values (not the labels) and injects them into the sql statement as a string e.g. '1,2,3'. The result would be IN(1,2,3). If you want to pass in a list of, say, countries then you would have to set the parameter values to be the same as the parameter labels So rather then Value =1, Label = Spain you would have Value = Spain and Label = Spain. Used in an IN() would generate something like IN('Spain', 'France').
If you try to do the same with a stored proc e.g. EXEC myProc #myParam, then the parameter values would be passed as a sing string which would then need to be split out by the proc.
If you just want to get a list of selected parmeter values or label shoing in your report then you can simply do something like
=JOIN(Parameters!myParam.Value, ",")
or
=JOIN(Parameters!myParam.Label, ",")
where "," is the delimiter
If you pop this expression in a text box, you'll get a list of the selected parmater values/labels
I think it's a kind of madness but I found a workaround to get a table of values from the results from SSRS. I query the IDs against a source table using IN(). I hope there is a better way of doing this?
SELECT [TblFeeBillingCycleID]
FROM [TblFeeBillingCycle]
WHERE [TblFeeBillingCycleID] IN(#intCycleId)

MS Access query based on filtered query

I'm trying to use a query (query2) based on another query (query1).
On a form where both are displayed, I use VBA to add filters for query1. This works for query1, but query2 keeps using the unfiltered query1 as its source no matter what I try. Any suggestions welcome
Many thanks
Two ways to approach this:
Approach 1: in Query2 set Filter on Load to 'Yes', then have your VBA add the filter clause to Query2 and re-run it. So, if you want to filter Query1 based on column [foo] having the value "bar", your VBA would add this to the Filter property of Query2:
Query1.[foo] = "bar"
Approach 2: Parameterize Query 1 - have it use a WHERE clause that points to a control on the form (perhaps a hidden text control if you don't want users to see it). The structure of your VBA would then:
1. change the value of the hidden control
2. Requery Query 1, which will now use the new parameter value
3. Requery Query 2, which will be based on the values of Query 1 (which points to the hidden control).

calling a query from a report textbox

I have a report based on a number of different queries. Most of the queries use the value of a row's customerID textbox as a key to extract specific data from other fields.
Here is what I have for the Control Source property of one of the textboxes:
=DLookUp([Level],[qryLevel],[Me].[customerID])
Here is the SQL for qryLevel:
SELECT TOP 1 Level, myDate FROM sometable WHERE custID=Me.customerID ORDER BY myDate DESC
qryLevel works when tested independently, but the DLookUp function does not seem to be working properly because Access gives a dialog box asking for each parameter and then outputs #NAME? in the textbox when no values are input into the dialog boxes.
How can I get each of these textboxes to output its own result from a separate query?
DLookup function arguments must all be strings: http://allenbrowne.com/casu-07.html
So for the first two arguments, just enclose them in double-quotes.
For the last argument, the documentation says it's equivalent to a SQL where clause, without the word 'where'. Actually since you're returning only a single record from your query you probably don't need the last argument at all:
=DLookup("[Level]", "[qryLevel]")
Although, I don't see how qryLevel can work as an independent query since it refers to Me which implies a container object. Better to express as:
SELECT TOP 1 Level, myDate
FROM sometable
WHERE custID = [Forms]![MyForm]![customerID]
ORDER BY myDate DESC
... which will work in any context--inside or outside a form.

Efficient use of calculations in MS Access

This is the kind of thing I feel I should already know, but don't...
In MS Access, if a query consists of n calculated fields (say calc_1, calc_2, .... calc_n) but I only want to use a subset of them in a particular form or report - say calc_x, calc_y and calc_z - would Access calculate all n calculations when running SELECT calc_x, calc_y, calc_z FROM myquery and then return the ones I want, or would it be smart enough to only calculate calc_x, calc_y and calc_z?
In my case I'm using Access 2003 but presumably the answer is the same for all versions.
Access is smart and don't calculate not-visible fields.
Tried with Access 2003
Like #David, I did not believe #Andreas's answer at first. So I tested it myself as follows. I created the following function:
Function Watch(Val, Optional CalledFrom As String = "")
Debug.Print Val, CalledFrom
Watch = Val
End Function
Then I created a table named "Dummy" with a single field named "ID". I created a form and used the following as the form's RecordSource:
SELECT Watch([ID],"ShowInForm") AS ShowInForm,
Watch([ID],"HideFromForm") AS HideFromForm
FROM Dummy;
I added a single textbox control with a ControlSource of ShowInForm.
I then opened the form and got this in the immediate window:
1 ShowInForm
1 ShowInForm
1 ShowInForm
I then went back to the RecordSource and previewed it in Datasheet view and got this:
1 ShowInForm
1 HideFromForm
I'm not sure why the "ShowInForm" expression is evaluated three times in the form, but it seems pretty clear that the unused field, "HideFromForm", does not get evaluated.
To address #HansUp's comment, I went back and saved a query named "Qry":
SELECT Watch([ID],"ShowInForm") AS ShowInForm,
Watch([ID],"HideFromForm") AS HideFromForm
FROM Dummy;
Then changed the form RecordSource to:
Select ShowInForm FROM Qry
This produced the same result as before when I opened the form (ie, 3 lines of 1 ShowInForm). Interestingly, when I opened the RecordSource in datasheet view I got this:
1 ShowInForm
1 ShowInForm
In other words, it evaluated the ShowInForm field twice. Presumably, once in "Qry" and again in the RecordSource query.
The end result is still a confirmation of #Andreas's answer.
If you include the calculated fields in the SELECT clause of your report or form's recordsource, it will calculate them for each row AS IT IS RETRIEVED.
If you leave them out of the SELECT and include the calculations only in the ControlSource properties of controls on your report/form, then what you say is true.
Also, if you do any sorting/grouping on the calculations or put criteria on them, all rows will be calculated.
Thus, in this recordsource:
SELECT Field1/Field2 As Ratio1, Field3/Field4 As Ratio2, FIeld1, Field2, Field3, Field4
FROM MyTable;
...for each row that is retrieved, both calculations will be executed regardless of whether or not the result is used in the form or report.
If you want to delay calculations to the last possible moment, do NOT include them in the SQL recordsource, but just use them as the ControlSources of the controls that are displaying the calculations. However, this has the downside that you'll see the calculations painting onscreen in many cases.
EDIT:
It seems this may not be correct, but I feel there's something going on here that is not completely explained by #mwolfe02's answer. I'll just leave this here for further discussion.
I put calculations like this on the server side.. computed columns are awesome.
I think that Access finally got this feature in 2007, I don't know how people ever survived without it.