This is for a budgetary application developed in Access 2007, currently running 2010. The application was working fine. I identified a logic error in a query. While fixing it I realized that I could change the parameters from:
Month(budget.capture_date) = [forms]![f_budget]![tglMonth]
AND
Year(budget.capture_date) = Year([forms]![f_budget]![capture_date])
to simply:
budget.capture_date = DateSerial(Year([forms]![f_budget]![capture_date]),[forms]![f_budget]![tglMonth],1)
Should be fine right? My thought was maybe it would be slightly faster due to less function calls.
The queries worked correctly while testing and typing the parameter in manually when opening the query.
When opening the budget form via DoCmd.OpenForm with criteria, all of the subforms with the DateSerial parameter showed as blank. The field f_budget!capture_date used in the parameter did contain a value.
When opening the form manually every subform gave the following error (no error code):
This expression is typed incorrectly or it is too complex to be evaluated. For example, a numeric expression may contain too many complicated elements. Try simplifying the expression by assigning parts of the expression to variables.
So, after investigation, if you open a parameter query with DateSerial and just skip through the parameters you will receive the error above. If you enter the date manually, it will work correctly. If I open the form via OpenForm with criteria, there is no error, but all the subforms are blank. From there if I change to design view and then back to form view without closing the form, the form will work perfectly. If I close the form and open it manually I will receive the above error for every subform with the DateSerial criteria.
Note that using Year() or Month() and skipping through a query's parameters will just return no results, it will not cause the error above.
This one has me stumped. I've created a new db and imported everything in it, decompiled, repaired, added the DateSerial to the parameter list of the query ect. Doesn't matter, the behavior is consistent. Anyone have any insight?
Year() and Month() functions allow to pass NULL while DateSerail require valid Integers.
So query fail to run with empty patrameters.
Related
I have a form in MS Access that has an unbound control named boxReferenceMonthGtis that correctly displays a date.
This control Control Source property is =[GTIS_subform].[Form]![ReferenceMonth] which is a field of type Date/Time in a subform.
When I try to use this control in a query in the SELECT clause it shows this gibberish �䃤.
After reading this I added PARAMETERS [Forms]![Conciliacao]![boxReferenceMonthGtis] DateTime to my SQL, and the SELECT statement started showing the correct value.
However, If I try to use my control as a criteria to filter another field like:
WHERE DateSerial(Year([Departure]),Month([Departure]),1)=[Forms]![Conciliacao]![boxReferenceMonthGtis]
I'm prompted with
Data type mismatch in criteria expression.
What is weird is that if I filter the field [Departure] like:
WHERE ShippingTrack.Departure=[Forms]![Conciliacao]![boxReferenceMonthGtis]
There is no error!
What else I have tried without success
Same error (Data type mismatch)
WHERE CDate(DateSerial(Year([Departure]),Month([Departure]),1)=[Forms]![Conciliacao]![boxReferenceMonthGtis]
WHERE CDate(DateSerial(Year([Departure]),Month([Departure]),1)=CDate([Forms]![Conciliacao]![boxReferenceMonthGtis]
WHERE CVDate(DateSerial(Year([Departure]),Month([Departure]),1)=CVDate([Forms]![Conciliacao]![boxReferenceMonthGtis]
Does anybody knows how to make this work?
What is even weirder is that I have another query in the same database that I can use WHERE DateSerial(Year([Departure]),Month([Departure]),1)=[Forms]![Conciliacao]![boxReferenceMonthGtis] without any issue!
OK:
It could be that some records have Null for Departure.
My Problem
I have a fairly straight forward autoexec macro to perform a version control check for my split database. I have a table in the frontend called LocalVersionNumber, and a table in the backend called LiveVersionNumber. Each version number may have multiple values (ex. which version of the backend is being used, which frontend, etc). Because of this, the value in these tables are parsed via the queries __LiveVersionParser_Q and __LocalVersionParser_Q. Without going into too much wasted detail, the local version number should always be equal or greater than the live version number.
I wrote up a query that compared my local & live parsed values - and via IIF expressions, determined the logic to update or keep with current version. This test query ran without issue, but now that I've pulled the logic into a autoexec macro and I'm getting the error:
Cannot find the name '__LiveVersionParser_Q' you entered in the
expression.
I've double checked, and the table and fields are spelled correctly. I've even gone as far as to copy and paste the statement from the macro back into a query, and the query executes properly still.
The Code
(In Macro Builder not VBA - ugh)
"IF" Action
CDbl([__LiveVersionParser_Q].[DevelopmentVersion])
<=CDbl([__LocalVersionParser_Q].[DevelopmentVersion])
Then... execute my update frontend logic.
NOTE: For those asking "why use CDbl?", this is used because the version number is a text string with multiple values separated by ".". After parsing the versions, these strings are then compared by converting them to a double (using CDbl) to see which is greater.
Troubleshooting
As I stated earlier, this statement DOES work, just not in this macro. I've troubleshot it by using the following query (to keep it consistent, here is the 'design' view expression I tested rather than SQL):
Expr1: IIf(CDbl([__LiveVersionParser_Q].[DevelopmentVersion])
<=CDbl([__LocalVersionParser_Q].[DevelopmentVersion]),"OK","UPDATE")
Any suggestions? I feel like I'm missing something simple.
I have found a workaround (not a root cause & solution). If someone can provide a proper explanation of the root cause, I will gladly switch over answer credit to them!
But in the meantime, should anyone else run into a similar problem, here is my workaround:
Step 1:
As stated in my question, I have a query that runs the "IF" action perfectly fine. So I used that to output a Result field that states either "OK" or "Update".
Step 2:
I changed my autoexec macro to be as follows:
IF...
DMax("Result","__VersionControl_FinalTest")="Update"
THEN...
Run my update code.
ELSE...
CancelEvent
END IF
NOTE: I tried to use a simple statement of:
IF...
[__VersionControl].[Result] = "Update"
However, when I ran that macro, I again received the error 2482 ("cannot find the name...").
Why DMax is able to 'find' the __VersionControl_FinalTest query and the IF statement cannot, I do not know - but at least I'm back up and running.
I didn't create the report, but there is a (not data-driven) subscription. There is one parameter with a default value (no issues). Then there are two multi-value parameters. When modifying the (mysteriously empty) multi-value parms (after the report failed to run) I can select ALL for each and set to run once--and the process succeeds. A file is written out to the folder per my intentions.
But when the date to run is set to the next morning, the execution fails with a message about invalid parm values. When I go in to check, those multi parms are empty again.
How do I fix this? (dumb question, I know)
What am I doing wrong? (also, very non-specific)
What am I leaving out? (of this question)
How do I search for this issue on SO? (I tried, but I couldn't find anything similar; maybe I'm missing some terminology; my search terms were "ssrs subscription multi value parameter not saved")
I have a problem with a Reporting Services report. My report has two datasets, one that fetches the actual report data and one that fetches translated resource strings for displaying wherever literal text is used on the report. This dataset requires three parameters, a language set id, a language code and a string to match against resource names.
Following an example I found here (the reply by Miguel Catalão) I have created a multivalue parameter #Resources that will be populated from the resource dataset and a code function that looks up specific values from the multivalue query. This function will then be called from expressions wherever literal strings are used.
I think that this should work but I have run into a problem that I can't quite figure out a workaround for. There is a dependency problem in the #Resources parameter being dependent on the Resources dataset which in turn is dependent on three parameters; #LanguageSetID, #LanguageCode and #ResourceNameLookup. I have read that the order of declaring parameters is important so I have made sure that the last three parameters appear above the #Resources one and that all three of them have default values that will result in data being retrieved by the dataset.
Yet I am still getting the following errors when previewing the report; any advice or guidance would be most appreciated.
The report parameter ‘Resources’ has a DefaultValue or a ValidValue that depends on the report parameter “LanguageCode”. Forward dependencies are not valid.
The report parameter ‘Resources’ has a DefaultValue or a ValidValue that depends on the report parameter “ResourceNameLookup”. Forward dependencies are not valid.
I had the same error but it was due to something else. What I had done was created a Parameter in my report, then linked the Default Values to a Dataset.
This in turn added the parameters needed in the Dataset. Somehow, the order of the parameters in my list were changed. This is when I stared getting the 'Forward Dependencies are not Valid' error.
I then looked at another report that used the same process to link a Parameter to a Dataset. I noticed that the order of my Parameters were different. I simply went back to my new report, and used the up and down arrows until my Parameters were in the same order as the working report. This seemed to fix the error and work fine. Apparently the the Parameter that was using the Dataset needs to be below the Parameters that are used in the SPROC.
I this helps someone in the long run.
C/N: Parameter was being filled by a Dataset(Stored Procedure). The Parameter that was being filled was above some of the Parameters that it was expecting for the SPROC.
This was all caused by a stupid error I made. I copied and modified the code function from the post I mention but neglected to change the data type of the argument from integer to string, which mine is.
It seems rather odd that the error manifested in the way it did but I have gotten past that problem now, only to run into another that I ask about in another question.
I am looking for ways to track down where an SSRS error is occuring.
I have a report that is about 90 columns wide with multiple formulas. The problem that I am having is that on one of the formulas there is a divide by Zero error. I have implemented the answer from Robert Harvey in this question but I still get the error. I know that the answer works as I have tested it on a small report.
So the question is: How on earth do you identify where an error is occuring in SSRS when SSRS only reports that an error occured?
EDIT The error as displayed is
An error occured during local report processingAn error has occoured during report processingCannot read next data row for the dataset MainReportDivide By Zero error encounted
EDIT
Rather than use the IIF statements and others, I'd reccomend doing the following... Add a custom function to your report, go to report properties and the code tab. Create the following. To specifically identify the field that is throwing the error, you can change this to return a string and maybe "#OOOOOOPS" so it sticks out on the report.
Public Function SafeDivision(ByVal top As Decimal, ByVal bottom As Decimal) As Decimal
If bottom = 0 Then
Return 0
Else : Return top / bottom
End If
End Function
After adding this function, go to the expression view for all of the fields that you have where division will occur. You can execute this newly created function by typing in:
=Code.SafeDivivision(CDbl(1.24), CDbl(0))
ORIGINAL
If you run the report within visual studio, does it tell you which specific textbox/label/field the computation failed in? That should help pinpoint where the issue is coming from, but you could also make sure that you never perform the division with 0 in the denominator by looking at the code below...
//myBottom would be the value of the denominator
//myTop would be the value of the numerator
= IIF(myBottom <> 0, myTop / myBottom, "")
Follow Up
The problem ended up being the SQL Query. As part of the SQL query, I had as In clause like the following.
Select ID, Name, price/kg as unitpice from products where ID In (#ProductIds)
SSRS uses exec sp_executesql and string.replace to inject the ID's into the IN clause.
The problem I had was I would run the query in SQL Studio Manager. with all the variables entered and it would work as expected. but under SSRS it would fail with the divide by Zero error, and there was no real clear indication where the error occured.
After I made a copy of the report and deleted items one by one until there was litrally nothing left on the report to render and it still produced the error, I turned my attention to the SQL Query.
It was there that error was occuring. I only found it after using SQL Profiler to find out what SSRS was actually running.
After that it was relativly easy fix of deleting the offending line and returning the seperate parts of the divide and run it through the function that RSolberg suggested.