Search results

If that's truly the case, then storing loyalty amount in both places is actually fine. Did you write that VBA code that does the INSERT? Because the simplest way is modify that to get the LoyaltyAmount from the Members table and include it in there. Either with a Dlookup or by modifying the...

I think you need to ditch the multi value fields and fix your structure. Before I get into that, don't use spaces in table/field names. It's going to make coding/querying difficult later on. Use underscores (Like_This) or camelcase (LikeThis). In the database you posted you have a main...

Sort of easy, but not the right way to do things. You don't store data in more than one place in a database. Can the Loyalty amount of a customer change? If so, do you want to record those changes or do not care what a customers loyalty amount was 3 weeks/months/years ago?

You don't have a database you have a spreadsheet. Use Excel and this issue goes away. If you want to use Access I suggest you normalize your data (that's the process of properly structuring your tables/fields): https://en.wikipedia.org/wiki/Database_normalization

I now remember (and reviewed) your prior post about this new owner and what you are giving him. If I were him, I'd want a working system, lumps and all. Not only are you trying to change tires on a moving car, you're trying to switch drivers while doing so. I'd give the new owner a working...

What happened in the last 6 hours? You started this thread with one table (tblService) with 16 fields and now you've laid out a 49 table database that tracks everything? What's the real story here? Had a guy build a comprehensive database a few years back, he left and now you're the guy stuck...

First, read up on normalization: https://en.wikipedia.org/wiki/Database_normalization That's the process of setting up tables and fields properly. Then google a few tutorials and work thru them. Next, apply what you learn to your data and set up what you think is the correct tables/fields...

No, you were testing for the existence of a record, you didn't look up anything you didn't already know. Further, if you have two records with the same LDOW value the form would open to just one of them.

What's the point of that code? Your querying for the exact value you already have.

You may have missed my quote marks: My advice stands, but keep trying.

Nope.

I don't understand the premise. Why not copy the database and just delete everything 'inactive' related and give him that copy?

Let's call your tables tblFish and tblFlow. If the date/time date in tblFlow is a superset of tblFish, you can easily do this with a LEFT JOIN: SELECT *.tblFlow, Fish_Count FROM tblFlow LEFT JOIN tblFish ON Flow_DateTime = Count_DateTime However, I don't trust your data--or anybodies data...

Yes, I would put it in an IIF statement. You test for the 2 possibilities that result in NO and then have everything else be YES: IIF((fldIgnore=True) OR (fldIgnore=False AND fldDiscNo>0 AND IsNull(fldRecordingID)=False), NO, YES)

3 binary criteria yields 8 possibilities. You've only addressed 2. True True True = "Yes" True True False = "No" True False True = ? True False False = ? False True True = ? False True False = ? False False True = ? False False False = ?

Lots to unpack: 1. Why is DoCmd.RunSQL a no no? Sounds like a valid way to achieve this bad idea. 2. The invoice number is ephemeral? You calculate it, use it, update the table with it, but then its gone with the next update? The invoice number exists only on this report and is not...

Words aren't going to work to explain this. We either need a sample database and precise instructions as to what you need where. Or we can just convert this to a data problem and you can provide sample data to demonstrate your issue.

Yeah, when building a house just slop some concrete in a hole, throw in some rebar and build on top of it. In a year or two--after you've done the important things like paint the 4th bedroom the proper color of eggshell and chosen the right cabinet fixtures for the third floor bathroom you can...

Agree with Isaac. If anything the warning should be to responders--people intending to provide advice to questions asked years ago.

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...