So I have literally used the same code format on 4 other Forms:
Here's the working code from those three forms :
=DMax("ID","tbl_Users")+1
=IIf([lst_DeviceType].[Column](0)="Cell Phone",DMax("DeviceNum","tbl_Cell_Tab","DeviceNum < 70000")
+1,DMax("DeviceNum","tbl_Cell_Tab")+1)
=IIf([frm_type]=0,DMax("DeviceNum","tbl_PC_Lap","DeviceNum < 100000")+1,IIf([frm_type]=1,
DMax("DeviceNum","tbl_PC_Lap","DeviceNum < 50000")+1,DMax("DeviceNum","tbl_PC_Lap","DeviceNum < 40000")+1))
=DMax("DeviceNum","tbl_Printers")+1
The goal here is to pull the current largest number in the Key from the table and from it get the next one in line so as to be calculated and stored for use later in a module that will audit changes to the tables. So I am using the format DMax("DeviceNum", TABLENAME) + 1
My latest form won't accept this format, instead throwing #Error
=DMax("DeviceNum","tbl_ThinClients")
And for the life of me I can not figure out why I keep getting this. I have deleted the textbox, and recreated it.
Here's a snip of the table in design mode
Here's a snip of one of the tables it works with
Any ideas as to why? I mean the only difference I see is that the Printers is a "Large Number" Data type (Values > 80000)
So apparently, though I don't know why, you can't DMax Large Number fields. The solution was to set it to a "Number" and use that.
Related
Hello I have been trying to return the result of a DCount within an MS Access form. I have a field called "Process" which stores a process such as "Shipping" and Sub-Process field which stores text too e.g. "Engineering". I have another field which needs to store the count of how many shipping processes have a specific sub-process such as answering "how many sub-processes are there for each process?" called txtcountsubprocesses.
The related text field is saved as txtprocess and the count field (the one I can't seem to get right) has the name txtcountsubprocesses. In the Control Source property for txtcountsubprocesses I have the following expression:
=DCount([Sub Process],[LogisticsData],[Process]=txtprocess.text)
I receive the following error message: #Name?
I have tried multiple other ways of programming the DCount however the way mentioned above seems to be the closest I have to a possible answer. I have also checked the spelling of the table headers from [LogisticsData].
Is it possible to solve my problem using a DCount method like this?
Required output (sorry not sure how to put in a proper table):
Process ; Sub-process ; Sub-processCount (3 columns)
Shipping ; Engineering ; 5 (three pieces of related data - the number being what I need to produce)
Shipping ; Medical ; 4 (three pieces of related data - the number being what I need to produce)
Firstly, DCount needs string parameters to identify field and table name.
Secondly, if you want to include something from the current form, you can concatenate those strings, or use a form parameter.
Thirdly, you should almost never use .Text. Use .Value instead. You can only use .Text on controls that have focus.
So, with all these things fixed:
=DCount("[Sub Process]","[LogisticsData]","[Process]='" & txtprocess.Value & "'")
You might want to read into using parameters, since oddities might occur when the value is Null or contains single quotes
This is the screenshot of how the final output should look.
However, in the screenshot you will find that purchase total (calculated text label) is the sum total of the first order description Total (calculated at form level): Final Form view section display
The above screenshot result is the output of this formula
=[OrderDescription_tbl].[Form]![Total]
If I use this formula
=Sum([OrderDescription_tbl].[Form]![Total])
The output is #Error.
Troubleshooting I did,
I had created a grand total at the footer of the Subform using
the Sum function and visible parameter set to No and wanted to
reference the output to the Main form Purchase total. How to solve this problem?
However, in the screenshot you will see the number of boxes
count (Not calculated and is a table column), I used the same Sum()
function in the order_description subform. It gives the correct
output. Why is there a difference in output for the same function
one, against the Non-calculated table column and the other, a calculated form text label?
I have used this formula too
=IIf([OrderDescription_tbl].[Form]![Total]>0,Sum([OrderDescription_tbl].[Form]![Total]),0)
Output is still #Error
I have used an query which calculates sum total of each line item and tried to reference this query as
a)=Sum([Query1]![Expr1]) received #Error
b)[Query1]![Expr1] received #Name?
As an alternative to the DSum solution proposed by Kostas, you can use the following workaround:
in the footer of the subform, insert a textBox with the =Sum([Total]) formula, name the textBox BigTotal (or whatever you want)
in the main form, refer to that control: =mySubFormControl.Form!BigTotal
make the subform's footer hidden if you want.
If you have large data sets, this should be faster than the DSum. Also if the subform has an embedded query as its recordSource, you avoid the creation of a queryDef.
Try the DSum() function:
=DSum("[Total]",[OrderDescription_tbl].[Form].[RecordSource])
Thanks! I have been able to solve it using the existing structure only. In this regard I referenced Northwind database.Although,my database would have been more specific and different from Northwind,some aspects from Northwind did give me hints on what to change. The trick was - I had several lookups fixed on numerical columns like unit_rate(and this unit_rate referred a product portfolio table containing product offering of our company).Once, I removed the lookup aspect of these column values, #Error as well as Name? error were automatically resolved. I created a grand total with Visible parameter set to No inside the order description subform and referenced the output of this form to the grand_total text label in the outer form as seen in the screenshots shared.😀 Thank you for the support#Ren Kessler and I will share this is Stackoverflow too so that others can take advice from my case scenario. Ren Kessler I will use your method in some other way,may be in this development scenario but for some other context. I found it quite interesting and I havent tried it. Apart from my reply, I would like to quote you and your solution method too.Total_Calculation_subforminternal_view_Expression_builder_for_grandtotal_textlabel
This is the solution Given by Ren Kessler(Facebook group member):" I solved it in a very convoluted way. I hope someone has a better solution than mine.
I created a series of fields on my form (not fields in a table, but just on the form) that reference the fields on the subform. Then I performed all my math using these form fields. It was the easiest way I could find.
It seems clumsy, but works. As well, it made it easy to use these fields on a report (in my case, an invoice).
In previous versions I did not have to do this. I took a 2002 app where the math worked on the sub form, and used the exact same steps in 2016 and got #error, just like you. This system solved it, but it just doesn't seem right."
I am attempting to maintain and fix a horribly out-of-date CRM designed by an ex-employee ~4-5 years ago in Access 2007. I have brought it into Access 2013 and fixed a ton of stuff up, but I am still running into many problems.
I spent a good 4 hours today attempting to figure out why certain values didn't line up. These values were being pulled from a SELECT statement on a Combo Box over a stored Query which simply returns a table with a few extra rows. Great.
However this value (a number) doesn't appear to correlate with what we expect. I enter in one value, save the ticket, and a completely different value gets stored into the table. Opening up the ticket, I see the value that I expect. Digging deeper, I found the following difference:
Set value_1 = Me.RegistrationID // What's being stored in the table
Set value_2 = Me.RegistrationID.Column(0) // What we expect
Surprise surprise! This is a Combo Box and some value is being stored in the table. The Control Source is "RegistrationID" and the Row Source is the query in question.
However I do not know what it is! This specific value correlating to the Combo Box appears to pull the correct data when we later open the tickets. However I have a strong feeling that this could be why many tickets from before one of the rows was deleted all appear to have invalid RegistrationID's.
How badly can this break?
How easily can we correct tens of thousands of tickets?
How can I fix this to store the correct value?
This is what I expect is happening.
Your combo box row source is based on a Select query which returns and displays multiple rows. For example:
Select RegistrationID, CustomerID, CustomerName From MyTable;
The Control Source for the combo box is bound to RegistrationID which is part of the Forms Record Source.
The issue is the bound column. If we set the bound column in our example to 1, then we get the behavior your are describing with:
Set value_1 = Me.RegistrationID - Set's value to CustomerID (may appear correct)
Set value_2 = Me.RegistrationID.Column(0) - position 0 from our query (RegistrationID)
Further building on our query example, you can say:
Me.TextBox1 = Me.RegistrationID.Column(0) - RegistrationID
Me.TextBox2 = Me.RegistrationID.Column(1) - CustomerID
Me.TextBox3 = Me.RegistrationID.Column(2) - CustomerName
The RegistrationID is what normally should be stored in the table.
As long as your form shows any values that directly relate to this RegistrationID you're fine.
I would start by checking to see under the format setting to see if column widths are set properly and I would also check under the data section to see if the bound column is correct. I might also throw in an after update macro/vba sub routine that saves the record. Hope this helps.
This is specifically for MS-Access Web Databases (requires Sharepoint hosting) which has many limitations compared to their client counterparts, like no VBA, instead you get form macros and data macros to manage data.
I've run into a weird bug on one of my applications. I have a query used to check stock levels against a "minimum stock level" also saved in the table. The query is pretty intense and there are over 4,000 records now to check against. These querys normally take about 75s. So I have made a little label that gets updated every time the form is loaded showing the time and date the query was last run, and the duration in seconds it took. (so users can see how fresh the data is and decide if it needs to be run again)
Now, the weird thing is it works fine in my Access client, but when I sync my changes to the server and try it in a web browser I get a "type mismatch" error. A small table is used to store the start and end times whenever the query is run, that's how I get the timestamp data. These fields are in a "Date/Time" format, obviously. But it seems the problem here is changing the date format to a string format so it can be put in a label on the form. The Access client seems perfectly capable of doing this, while the web client stumbles and falls.
My problem is, how do I change data in a date/time format to a string format in a Web database? I can't figure out how to do this. The tools are so limited. I may have to end up answering my own question here but I'm posting this for others just in case.
To return a value from a data macro as string, you have to format the internal date/time format as a string. In Access an internal date/time value is a double number with the integer part as number of days since 1900, and the “decimal” time part is a fraction of 24 hours. Unfortunately if you simply wrap the date/time in the str$() function we had for 20+ years, then you get something JUST like if you type this into the debug window:
? cdbl(now())
41955.5478587963
The solution is to simply pull out each part. And “nice” is while in few cases a data macro will cast the data type, it does in this case and thus the STR$() command is not required.
The expression you thus can use is this:
Month([d]) & "/" & Day([d]) & " Time = " & Hour([d]) & ":" & Minute([d])
So say to pluck out the VERY LAST start time column from say a invoice table, since we don’t have a dmax(), then we simply sort the table in the order we want and pull out the first row.
Our data macro will thus look like:
Note how in above I simply typed in the SQL and SET the order on the date/time column. I want the MOST recent invoice start date and time. For those new to SQL, then I suggest you build a query in the query builder and specify a query in above lookup feature, since many are not "comfortable" typing in free hand SQL as I did above.
Now, in your browser side (UI) macro, you can use this code:
The above returns a formatted string that you can stuff into a text box, or as per above code change the caption of a label.
Unfortunately with silly problems like this, it becomes a path-of-least resistance thing.
Since my intended result was simply to get "a timedatestamp from a table to show up on a form (so users could see when a query was last run)", this became redesigning my form in Access to be a text field instead of a label. Text fields can be adjusted to accept "Time/Date" formats, so this is exactly what I did, it now pulls the timestamp data directly from the last record of the table and requires no extra formatting to appear in the web browser. I redesigned the text field to appear and function more like a label, and my desired function was achieved.
However, since my question specifically asks, "how do you change a time/date format into a string format in a Web db?", I will leave it here in case someone actually does solve it.
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.