Recent content by plog

1. The recordsource doesn't need to be a query, it only needs to be based on orders. 2. Order id probably doesn't need to be shown on the form. Are users using that externally of the database? If two people are talking do they reference data with the orderid? 3. There's no action button...

You really haven't given us a great view into the ultimate aim of what you are really trying to accomplish. You've taken a few steps down a path, that may or may not be the correct path, and are now asking for help on the path you have chosen. I'd back up a few steps and tell us exactly where...

I would do a UNION that feeds a cross tab: 1. Make a simple query for each status. Be sure that all 3 queries have the same SELECT aliases (StatusDate, Status). qrySubmittals: SELECT (DatePart("m",[Date1])) & "/ " & DatePart("yyyy",[Date1]) AS StatusDate, 'Submitted' AS Status FROM...

With DMax() https://www.techonthenet.com/access/functions/domain/dmax.php

I need better specifics to help you. My gut tells me a table might be the way to go after some revisions to your reports. But what you've given and explained isn't helpful. Since you haven't given me much to go on, here's my unspecific thoughts: 1. Your reports can be consolidated. I bet...

Maybe TABLE: the table would have fields: rptArea, rptName , strdisplayName , Reports(strReportName).Caption, Docmd.OpenReport "Finance1_rpt", acViewPreview I don't understand why you need all those fields. Doesn't the report itself have all those values in it? Why does it need to be taken...

I think season would just be a numeric field in the episode table. If you have other pieces of data that go with a season but not an episode nor the series, then you might need a seasons table. But I can't think of such data.

1. Non-null "Nulls". Your eyes cannot be trusted to see a null value. Just because it looks like there is no data in a field, doesn't mean it is null. It could be an empty string (""). It could be a weird character (line return, tab, something else). To a computer all those things I just...

You shouldn't have fields named after days of the week. Your adding bandaids on top of bandaids with the issue you posted about. The real fix is to normalize your data properly, then just bind forms to them so they handle the data adding, updating and deleting.

Why do you want it like that? Typically a 1 to many relationship (as in your 1 Customer to many Services) is done with a subform that scrolls vertically like so: ServiceNumberServiceType 1abc 2def 3ghi If you have more services to add to a customer, just keep adding new records...

What you have now is a 1 to many relationship. Your existing table is the 1 and that new table I prescribed is the many. With forms you use a main form to display just 1 record from the 1 table and a subform to show as many records as needed from the many table. Here's good documentation for...

Data, always start with data. The process of setting up your tables and fields is called database normalization: https://en.wikipedia.org/wiki/Database_normalization Presumably some sort of system(s) currently exists for this. It might be in a few systems--an app supported by IT, some...

Can you upload a copy of your database? If not, complete the Relationship tool, take a screenshot and then post it here. Before you move on to forms its best to make sure your tables are correct. I just don't want to miss any other issues that will mean re-redesigning the forms.

Agree with DBguy, you need to fix your tables not band-aid this. You are storing data in field names, that is an incorrect way to store your data in a database. A general rule of thumb is that field names should be generic (CompanyName) and not specific (Geico). So instead of a field for every...

Ha ha. Assumptive 'woulds' and 'shoulds' always puts a smile on my face. Not saying you are wrong, but in my experience data reality very rarely matches peoples assumptions about their data. And very often to poor results. SELECT Customer_ID, Order_Date, Order_No, Item_Code FROM...