Search results

This depends on your needs. Frankly, I don't see how you would need so many adhoc reports. If a report is necessary it should be created saved and then reused when necessary. I'd rather have multiple reports with minor variations then try to create reports on the fly.

First I disagree with using a composite PK. You would want a unique index on the combination of Course and Student IDs, but I would use an autonumber as the PK. Second, I agree that the CourseID table is bad. I do NOT recommend taking attendance this way. Instead what you do is record ABSENCES...

Your structure is incorrect. If each Department as only one Contact, then you only need ContactID as your FK in the department table. There should be nothing about Department in the Contact table. On the reverse, if each Contact has only one department, but a department can have multiple...

Frankly, You shouldn't be taking money for something you aren't fully competent to do. I'm not saying you will never be competent, but its clear from your own admissions, that you were probably not ready to take on such a project for pay. That being said, you did the right thing by offering a...

Use UNC coding rather than drive letters: \\servername\sharename\path\filename Also, if you give the MDW file the SAME name as the MDB and put them both in the same folder, I don't think you need to specifically refer to the MDW. This is what I said initially.

You can setup code to to create a stored query from the filtered recordset. Then have the user use that query and build a report based on it.

This is one of the places where Access is very weak, There is no way I know of to programatically add controls or to build a report on the fly. The best you can do is hide controls and move controls depending on criteria. It is NOT a task I would even attempt. The next best option is to create...

Check the RecordSource of your form, if it lists a table or query its bound. If you want to be selective about the fields you print, that represents a problem. Creating dynamic reports like that is NOT easy. You are better off printing more data than you need.

A form doesn't have data. The controls on a form may have data if the form is unbound. Otherwise the form reflects the values stored in fields of the bound table/query. If the form is unbound you couldn't use the wizard to create a report anyway. If the form is bound, you can create your...

Two tables, tblPlayers and tblAdults. The latter table listing all guardians, staff doctors etc. Then add tblAdultRole AdultRoleID (PK Autonumber) AdultID (FK) RoleID (FK) (i.e. Guardian, Staff, Doctor) you then use the join table I mentioned previously to join adults to players.

HUH? If you want to use the Report wizard, then you need to select a table or query. Why wouldn't you create a query first? How do you expect the report toi know what data to use?

What you are describing is essentially a Bill of Materials application. You might want to search here and/or on the WEB for that phrase for more info about it. Besides your buyer and dealer info, you need at least five other tables: tblModels ModelID (Primary key Autonumber) ModelName MFgID...

I believe we have answered this before. Access security is controlled by an MDW file. When Access is installed it creates a System.MDW file on your PC. If you make changes in security without specifying the Workgroup (that's what the W stands for) filem then the security is made in your...

Reports and tables are different animals. Reports can be designed to look different form the tables. If you get your data tables setup correctly you should have no problem with reports. Basically you just want to use grouping.

No, we did not say to create "tables" for each spec. We said to create ONE table of specifications: tblSpecifications SpecificationID (Primary key Autonumber) LagerID (Foreign key) High Low ReceptacleID (FK) You would then have a table of Test results: tblResults ResultsID (PK autonumber)...

see mail merge feature in Word

I had several 97 apps running on a W2K server before we upgraded. No problems at all.

As someone else said, Access can do just about anything. You just need the time and resources to throw at it. As Pat said you need to create a table that lists the specs. This table would indicate the product and the parameters of the spec (in tank, keg, etc.). You would then be able to pull...

It should work in the After Update event of the Page control.

Yes, if you need to identify the primary and secondary supervisor, then you add a field to identify the relation. As to the other, I would go with the last example. You don't need the manager name, you get that from the ContactID (assuming they are all from a single table). So the best option...