I am trying to determine how a file path value on a shared server (output of the DLookUp function in Access) is getting populated.
I have a field on a Form that is getting it's Control Source from the following formula:
=DLookUp("[DefaultOuptputDir]","Defaults")
When I search in the VB Editor, I can not find any references at all to "DefaultOuptputDir" (the spelling is correct as it was originally created). I can also not find any reference to the actual Path being populated below, so I don't believe it is hardcoded in a form.
Ultimately I want to change this path to one I can access, but I need to understand how this is getting populated now. Looking for input on what I should be checking, thanks!
DLookUp is a function which searches table for some criteria and returns some field
DLookUp(field, table, criteria)
In your case it shows value of DefaultOutputDir in table Defaults and i suspect this table have only one row so the third argumet is ommited.
That will be the value stored in the first record of a field called DefaultOuptputDir In a table called Defaults.
Related
I was wondering if it is possible to have a Lookup function that populates the textbox even when the condition is not met?
In the following example, assume that a table is bound to a dataset("TeamTasks") that includes a field for the identifier RelatedProject. A separate dataset called "TeamProjects" contains the corresponding Project and the Project name Title. In the following expression, Lookup compares the value of RelatedProject to (Project)Title in each row of the dataset called "TeamProjects" and, when a match is found, returns the value of the Name field(Title) for that row.
=lookUp(Fields!Related_Project.Value, Fields!Title.Value, Fields!Title.Value, "TeamProjects")
My question is, is it possible to retrieve the Project title even when the condition is not met. I.e. when there is no task with a relatedproject identifier. Ideally it would still return the project title and have its linked task coming in as Null. It is important for me to have no values left out and I'm not sure what other way I could accomplish this.
Thanks!
Using SSRS 2012
I have a multivalue parameter in a report and I would like to make it the source of a table. Is there a way to accomplish this? I'm coming to the conclusion that one cannot make the data source of a table anything except a dataset.
I tried to make the multivalued dataset (source of parameter) filtered by parameter but that gives a forward reference error (makes sense).
I am now trying to set the visibility property on the table's single text box like this, so it will only make the values visible that are one of the chosen parameter values:
=IIF(Fields!MODALITY.Value = Join(Parameters!Modalities.Value,","),True,False)
but they are all shown (alway true?). Any ideas on how to show a list of the values picked from a multi valued parameter in the report as a table (not just a delimited string in a text box)?
The data source of a table will always be a dataset, but you can use the parameters in a dataset. Something like
select * from dbo.split3(#parameter)
where split3 is a csv to table function, like one found on http://blogs.msdn.com/b/amitjet/archive/2009/12/11/sql-server-comma-separated-string-to-table.aspx
I found an expression that works for changing visibility so that my table shows just the elements in the multivalue parameter that were selected. Perhaps there's an easier way.
=IIF(Instr(","+Join(Parameters!Modalities.Value,",")+",",","+Fields!MODALITY.Value+",") <> 0,False,True)
I have an Access form with a textbox bound to a currency field in a table. As expected, anything other than a numerical entry generates an error. Occasionally, users need to enter several amounts and have those added together and the result entered into the currency field.
To accomplish this, I would like users to enter an equal sign followed by a valid arithmetical string which would evaluate to a number exactly as they would in an Excel cell. For example, if a user enters "=5.31+2" I want the field to evaluate to "7.31" and use that as the value passed to the table when the record is updated or saved. The current workaround is to use the Calculator application but that isn't the ideal solution.
I tried the following code and applied it to both the BeforeUpdate and OnLostFocus events of the textbox (named "tbxTotal_Paid") but neither worked. I simply got "The value you entered is not valid for this field" error.
Dim charCt As Integer
Dim evalStr As String
If Left(tbxTotal_Paid, 1) = "=" Then
charCt = Len(tbxTotal_Paid)
evalStr = Right(tbxTotal_Paid, charCt - 1)
Me.tbxTotal_Paid = CCur(evalStr)
End If
Is this simply applying the code to the incorrect event or is this a coding issue? Any assistance is appreciated.
For me your code looks fine but you might put it in the wrong place.
Like you said Acess is giving you this error because the textbox is bound to the currency-field. So it will never accept non-numerical values because the value-checking code fires even before the before_update-event.
I think the best solution would be to hide your bound text box using Me.tbxTotal_Paid.Visible = False and creating a surrogate textbox which is not bound. You put your code in the beforeUpdate-Event or Change-Event of your surrogate. At the end you should check your final result with IsNumeric(). That way your surrogate textbox writes only correct values to your bound hidden textbox and only numbers arrive at your table.
An alternative would be to change the currency column to a string-field but this would not be wise because of potential wrong data in your database.
I have an Access database that uses linked tables residing on a SQL Server. For one of these tables I created a simple form showing several fields of the underlying table.
I want to switch records using a combo box, so I added one using the Combo Box Wizard, where I selected the option "Find a record on my form based on the value I selected in my combo box".
The combo box works, but I noticed that whenever a new value is selected, Access will briefly return to the first record before displaying the selected record. I can verify this by both noticing a screen flicker (e.g., bound fields briefly display data from the first record), as well as profiling the calls to SQL Server, where I can see one query for the first record, and another query for the selected record.
This problem does not occur if I use the next/previous Navigation Buttons at the bottom of the form.
How can I avoid this unnecessary query?
What using the Wizard did was create a Macro behind the Event of your combobox click. It probably looks something like .. , , First, ="[SomeField] = " & Str(Nz(Screen.ActiveControl,0)) .. What you can actually do, instead of using the Macro, is follow something like this
If we look at what that Macro does (or what arguments it accepts), it is a little more clear on why you may be experiencing that behavior.
The first argument is Object Type then Object Name, then Record, then Offset.
Object Type - The type of object that contains the record you want
to make current. Click Table, Query, Form, Server View, Stored
Procedure, or Function in the Object Type box in the Action
Arguments section of the Macro Builder pane. Leave this argument
blank to select the active object. <- Yours would be left blank because you're referring to the combobox on the form
Object Name - The name of the object that contains the record you
want to make the current record. The Object Name box shows all
objects in the current database of the type selected by the Object
Type argument. If you leave the Object Type argument blank, leave
this argument blank also. <- Because the first was left blank
Record - The record to make the current
record. Click Previous, Next, First, Last, Go To, or New in the
Record box. The default is Next. <- This defaulted to First for me and possibly for you too, probably why you were seeing this 'odd' behavior
Offset - An integer or expression that evaluates to an integer. An
expression must be preceded by an equal sign (=). This argument
specifies the record to make the current record. You can use the
Offset argument in two ways: When the Record argument is Next or
Previous, Microsoft Office Access 2007 moves the number of records
forward or backward specified in the Offset argument. When the
Record argument is Go To, Access moves to the record with the number
equal to the Offset argument. The record number is shown in the
record number box at the bottom of the window. Note If you use
the First, Last, or New setting for the Record argument, Access
ignores the Offset argument. If you enter an Offset argument that is
too large, Access displays an error message. You can't enter
negative numbers for the Offset argument.
I wish I could give you more details, but I have not used Access in conjunction with SQL Server, so if that plays into account I would not have any insight.
So, I have a problem in Report Builder that is just driving me absolutely crazy.
I have two dataset; one called DS_Grades and the other DS_Pupils. I want to do a simple LookUp based on PupilID, a field that is in both datasets, and return a grade from DS_Grades into a Matrix based on DS_Pupils.
The formula I am using is:
=LookUp(Fields!PupilID.Value, Fields!PupilID.Value, Fields!Grade.Value, "DS_Grades")
I have confirmed that:
1) DS_Grades has the right PupilIds
2) There are actually values in the Grades field
3) Both PupilID fields (I.E. in both datasets) are definitely Integers and not text.
Moreover, if I add a calculated field to DS_Grades called "test" and populated with the value 208301, which is a valid PupilID, then I can enter the below formula and it works fine:
=LookUp(208301, Fields!test.Value, Fields!Grade.Value, "DS_Grades")
So, the LookUp itself must be matching properly, which means that the PupilID fields must be causing the problem, but I have quintuple freaking checked them and they definitely have the right values, in the right format. I am at a total loss as to why SSRS thinks that they don't match.
Help please!
Got it! Some filtering was at Dataset Level (instead of query where I normally do it) that was throwing the whole thing out of joint. Removed that, and it's fine.