Search results

It looks to me like you have things set up nicely with StudentID as the primary field in tblStudent_Demographics and also as a secondary field in most of the other tables so that in queries there can be JOINs as needed. As with theDBguy I also notice that with an implied 1-to-1 relationship it...

I wonder if making the underlying field in the table a Memo field would help. And/Or How about in the textbox control change the New Line in Field property from Default to instead be New Line in Field.

It seems to me that in general if a query is showing the records you want then all you need for a form to also show those same records is to set the form's RecordSource property to be that query and no other code or filters etc on the form would even be needed...

And here is an article about using a multi-select listbox as criteria for a report (and a tricky part here is looping to add items to the SQL WHERE clause): Use a multi-select list box to filter a report

Here are a couple multi-column forms that you might be able to use as a starting point... http://www.cecv.catholic.edu.au/getmedia/5b474d06-cadd-40d9-a5b9-e14f727b3d0e/Electrical-Equipment-Register.aspx...

And to be sure to show data for just the one client on the report page: In each subreport control... Link Child Fields: ClientID Link Master Fields: ClientID

And fleshing out what theDBguy said a bit, on the subreport control... Link Child Fields: Department Link Master Fields: Department

Here's a related article that EMULATES a tab control to thus allow for various background colors of the "sheet or body below the tab": https://www.fontstuff.com/access/acctut12.htm

Just to throw in another related approach. In general here is how I often do time difference calculations using the DateDiff() function: ElapsedMinutes = DateDiff("N", OlderTime, NewerTime)

And fullest answer looks like here: https://stackoverflow.com/questions/45332357/ms-access-vba-error-run-time-error-70-permission-denied

Another thing to consider that MIGHT be somewhat helpful is that DLookup can be based on a table as was discussed above OR it could be based on a query (but not the same query that it is being used in as that would be circular).

So in summary to kind of put it all together... To show data like this: A 3/11/2019 209 A 3/12/2019 169 Could possibly do something like this: SELECT [UserID], [EntryDate], Sum(DateDiff("N",[TimeIn],[TimeOut])) AS ElapsedMinutes FROM MyTable WHERE (([EntryDate]>=#1/11/2019#) AND...

Here's one I like: SQL Tutorial w3schools.com/sql/

Without creating a pay rates table, you could do the following... - In the employees table have a rate field (which of course is the latest current rate). - Also in the paycheck table have a rate field (which is the rate for that employee at the time of that paycheck). - And then when creating...

No offense intended, but I probably wouldn't trust the installation process of a front end (no matter how seemingly simple) to a possibly unsophisticated user - I'd do it myself especially if there hopefully aren't too many local PCs. And then of course I could give each one a quick test too...

Since I've already created many databases, when starting a new project I almost always try to figure out which one that I've already done that it would be closest in design to and start with a copy of that and then add/edit/delete stuff as needed...

Or if didn't want to make many changes you could have a macro called AutoExec which would get run each time the database is opened and in there have a RunSQL command with your existing SQL statement.

How about something like this: Assuming that you already have the combo box working the way you want (perhaps using UNION and/or DISTINCT etc.) then for the SQL to produce the proper records... SELECT * FROM Contacts WHERE (Contacts.Name = Forms!MyForm!MyCombo) OR (Contacts.Surname =...

And specifically with regard to your question: Well if you follow Cronk's advice then the "parent" table of machines doesn't actually need to be "populated" with anything new concerning a new part for that machine. Just the "child" table of parts needs a record containing the "parent" table's...

And along the same lines how about this: Keep the Access database on the C:\ drive and store all the filenames (but not the full file paths) in the database. And also have a table called something like Locations with data such as C:\MyFolder\MySubFolder and E:\MyFolder and thus be able to set...