How to call any function in Microsoft Access? - ms-access

I've what seems a trivial thing to do in MS Access 2016, but can't get it right.
I have a table named "Values", and I want to get the Length of a column named Value_Name which is of data type "short text"
So I click Create > Query Design. I show table "Values". I double click column "Value_Name" so it's the first field. I click in the second column, and for a Field value I enter:
Length of value: Len(Value_Name)
If I click anywhere else, I get a pop-up error saying "There was an error compiling this function. The Visual Basic module contains a syntax error." When I close the error it highlights "Len" in my Field.
I've tried with several functions (replace, left, etc) and can't get any to not give the above error, even when adding the column with the "Build..." right click menu.
So I edit the SQL directly, and enter:
SELECT Len("Test") AS TestLength;
And this gets "Compile error. in query expression 'Len("Test"'.
... and yes, the error message has a period after the word "error" for some reason.

In queries specifically, this issue occurs when VBA has a problem compiling some code.
As June7 hinted, it may be caused by a missing reference, but only if there's some VBA code failing to compile. It can be code with plain syntax errors too.
To track down this code, enter the VBA editor (Alt + F11) and hit Debug -> Compile Database. The editor should point you close to the code that's failing to compile, which you'll have to fix.

Related

MS Access load text box with multiple values from other form

I've got a quick Access database update I need to do and it's been years since I've touched Access. What I need to do is take a text box, and have it pre load with two values from another form. So far I've tried just adding them from the controls menu and I get nothing but errors. In the data menu on the property sheet, I edit the control source and put the following:
= «Expr» Forms![AFR]![SerialNo]
so I'm trying to load the SerialNo field value from the form AFR. But I get the error message "The expression you entered contains invalid syntax. You may have entered an operand without an operator."
Any ideas what I'm doing wrong?
The problem is that Access has tried to be helpful, and entered the "" in for you which is not needed. You should use this instead, probably as the default value:
=[Forms]![AFR]![SerialNo]
Note that if form AFR is not open when the second form is opened, then you will get an error of "#Name?".

MS Access - "Cannot Find the Name... In the Expression" error - IIf CDbl statement

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.

Type Mismatch (Error 13) when populating a null field in VBA

I'm trying to populate a control from an external form with a string value on button click - this is working perfectly when there is already existing text, however if there is nothing then it is treated as a null value and therefore returns a Type Mismatch error.
I thought I would be able to work around this by using:
Nz(Forms!frmSpecifications!boxScratchpad.value, "") = "Text string"
But this hasn't worked.
Could it be to do with how I am calling the control, or the properties of the control itself?
UPDATE: After looking into this a bit more I have pinpointed the issue to a SQL query execution earlier in the code which runs an update statement on the same table that boxScratchpad normally gets its data from (although the field which is fed into boxScratchpad is not actually updated). If I comment out this code so that the update statement doesn't run, boxScratchpad populates successfully. It seems like there could be a conflict between the table being updated and boxScratchpad being assigned a new value within the same code?
First of all, understand what you are trying to accomplish and what your code does.
Assuming your control is a textbox, the property that displays its text is value. If your control is a button, the property that displays text is caption.
You are trying to assign a string to this control value or caption, there will be no issues if those properties are currently NULL.
The mistake lies within the nz. If nz evaluates your control's property to NULL, it will return your empty string as the answer, thus ending in this situation:
"" = "Some text"
Which will throw error "It requires an object".
Remove the nz function.
To really test the interference of your SQL update with the control, use the inmediate window in vba editor to execute and test your code.

SSRS 2008r2: rsRunTimeErrorInExpression: cannot find textbox stated in warning

I am using Sql Server Reporting Services 2008 R2. When "previewing" my current report, I see everything appearing as it should. The displayed query values are correct in my table, which reads straight from the single dataset.
However, I see this as a warning:
Warning 1 [rsRuntimeErrorInExpression] The Value expression for the textrun ‘Textbox20.Paragraphs[0].TextRuns[0]’ contains an error: Input string was not in a correct format. E:\SSRS_Projects\Custom Reports\Attendance\Attendance\MIA_1B_Math_Absence_Detail.rdl 0 0
The puzzling thing is that I have no objects named "Textbox20."
I tried browsing thorough the object list on the "Properties" panel
and didn't see it.
I did a Ctrl+F search for "Textbox20" and couldn't find anything.
I'm not sure what else I can describe at this point.
Does anyone know how I can isolate the cause of this warning?
Thank you
If I understand correctly, the warning message was caused by the incorrect previous expression, however, the warning message persists although the values displays correctly in the report after you modified the expression. Besides, the warning message came out even though you create a new report and use the right expression.This is a known issue in Report Designer. When there is a warning message generated in the "Error List" pane of the Report Designer, the warning message still pops up after we correct the previous error. Actually, it always pops up whenever we preview any report in the same project. To avoid the issue, we only need to close the project and reopen the project. That way, the previous error lists will be cleared and the warning message won't pop out unless there is still an error in the report design.And your table's columns and rows are here text box.so please select the table column and see the property name.
Try Using this code
=IIF(IsNumeric(Fields!Data.Value),CSTR(FormatNumber(IIF(IsNumeric(Fields!Data.Value),Fields!Data.Value,0),2)),Fields!Data.Value)

What are the best strategies to debugging SSRS?

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.