Recent content by plog

It sounds like you know vacancies and then you assign candidates. So I would stick with the main form being based on (one record from) Vacancies and the subform based on (many records from) Candidates...

What's your real world workflow? 1. How do vacancies come about being entered in the database? A bunch at a time or just one every so often? 2. How do candidates come about being entered in the database? A bunch at a time or just one every so often? 3. Who enters vacancies and candidates...

Yes, sort of. Broad strokes--I don't do this once-- I build a process to do this and make that process airtight. Once the process is built it, I run it one final time and have full confidence the data will migrate succesfully because I have worked out the kinks and fixed all the data. That...

GpGeorge got it right in his first post -- you shouldn't be doing this. You can achieve what you ultimately want, but this is not the way to do it. You don't store both age and date of birth in a table because age can be calculated off of date of birth. Further, age tomorrow isn't guaranteed...

I've played this game before many times on this site, but willing to do it again for you: I strongly suggest you use autonumbers and forget this ultimately useless amalgamation you think is the right solution. Here's where you say--"But we need all that information crammed into a string...

You don't need the _1 tables in there, you only need each actual table in there once. However... 1. Remove the _SuccesfulID fields from VacancyCandidate_Tbl and replace it with a Yes/No field called Success, default it to No and if they are successful change it to Yes. You now know if they...

I've got the right help, but not help you are going to want to hear--I think you have set up your database tables incorrectly. The little we have to go on raises a lot of red flags. The Detail section doesn't use any data from the report. It uses DSums which have their own data source...

You need another table---VacancyCandidate. Since a single vacancy can have multiple candidates and a single candidate can go to multiple vacancies you need a table to sort all that out. This is what that table looks like: VacancyCandidate vc_ID, autonumber, primary key vc_DateTime, datetime...

Words rarely working in describing how you want a query to work. Example data is the way to go. Give us two sets of data: A. Starting data from your data source. Include data source and field names and enough rows to demonstrate all cases B. Expected results from A. Show us what data...

You're asking us how to use duct tape to fix the wood putty that you used to fix your cracked foundation. Actually, that's not a great analogy because your root issue isn't as bad as a cracked foundation. It's actually really trivial to fix. Don't store this value, calculate it. You make one...

First, I don't think your products table is a products table, it's an inventory table (e.g. QuantityUnit, WHID). You are storing a ton of duplicate data that should go into an actual products table (BarCode, ProductType etc.)I think you do need a products table--one that just lists all the info...

Think we need more specifics. I have two hunches based on nothing you've said, just experience here: 1. Your math could be more efficient. 30 fields based on 15 inputs is a lot, and then you say that some calculations feed into other calculations downstream. Perhaps some of those...

You're printing out a value on the form, not a value from the record set.

"R915" doesn't look like a number to me. Are you using base 28 or more? In a table, you should store your values with the data type they need to be. If you will be doing math on data then you should store them as numbers. That means the "915" part goes into a field by itself as a number, and...

You can't have it both ways. Either you get a list of unique artists because the artist names are distinct. Or you get duplicate artist names because record_id/artist name is not distinct to artist.