• ** There has been a recent site upgrade. Please clear your browser cache to avoid issues. **
  • New forum feature - post voting and best solution

    Check out this thread for the details: https://www.access-programmers.co.uk/forums/threads/new-forum-feature-post-voting-and-best-answer.314134/

    This new feature looks great to me! :)

  • We now have 3 forum themes

    Go for the default (light) theme, Shades of Grey or Shades of Blue. I just added the Blue one.

    The thread about it is here: https://www.access-programmers.co.uk/forums/threads/new-forum-theme-shades-of-blue.314136/

Best practice for completing a proforma document (1 Viewer)

liddlem

Registered User.
Local time
Today, 04:41
Joined
May 16, 2003
Messages
332
Hi All
At the boarding school that I work for, students frequently run away.
If we are unable to track them down within 24 hours, we are obliged to file a 'MISSING PERSONS' report with the police.

I am able to extract much of the information (Student details, parent and family member contact info etc) from our database.
However, there are two other groups of data that the police require, that we generally do not store in our system.
1. Descriptive info - (Height, Weight, Build, Complexion, Hair colour, Teeth description.)
Other info that helps with the investigation (is the student : Armed, Suicidal, Have Infectious diseases, Violent nature, etc )
Most of the above, we might want to store for future instances.

2. Investigation notes - These are 'progress notes' that the police complete during their investigation (Student bank account, last seen at etc)


I have built forms and queries etc that displays the 'known' information, but
A. What is the best way to treat the 'unknown' data (that we generally do NOT store) . . . for example: Should I create a form to gather the info at run time, or do i go the 'whole nine yard' and create additional table(s) to store the information - bearing in mind that things like 'Height','Weight' and 'Hair Colour' might change over time, but 'Build' and 'Complexion' are generally static.
The current method of filling in a blank form is labour intensive (even if the 'known' data is pre-populated), so I want to make the process as simple as possible, BUT I also don't want my user to get lazy. (IE ignore the 'changeable' info when filling out a new report.)

B. Do you have any suggestion on the most efficient/effective/best practice method that users can complete the required documentation...IE: Would you create an access form(s) and then produce an ACCESS REPORT... OR would you create a WORD document that links to a (temporary) table in the database and have the users complete the info in Word? (Can the WORD document write back to the ACCESS TABLE(s) - assuming it is being stored?)

Thanks for your time.
 

Ranman256

Registered User.
Local time
Yesterday, 23:41
Joined
Apr 9, 2015
Messages
3,618
a. have a table to add anything 'items' for that person
id, item, value
23, build, endomorphic
23,favorite meal, tacos

B. i would rely on internal Access report. Its built in, and theres no confict or errors that could happen with Word.
 

Pat Hartman

Super Moderator
Staff member
Local time
Yesterday, 23:41
Joined
Feb 19, 2002
Messages
29,690
A. Put the data that may change over time in a separate table and date it. You can decide how frequently you need to look at changeagle data and create queries that trigger a review of every record that is over 1 year old - or whatever seems reasonable. Perhaps the younger the child, the more frequently the data should be reviewed.

B. The simplest method is to create an Access report. You can then export the report to a PDF and email it, print it, or fax it to whomever needs it.
 

aaronkempf

New member
Local time
Yesterday, 20:41
Joined
Jul 7, 2020
Messages
14
I used to work on a team that used SQL Server Reporting Services, and then we wired SSRS into a product that allowed people to CUSTOMIZE the reports in word before sending them. It was a royal pain. But to ME? I'd move to SSRS and ditch Access Reports entirely. I mean it might not be SIMPLE, and it might cost MONEY, but professional reports to ME, they just don't happen in MS Access.

I'm not trying to be negative. But for example, if you want to automate emailing Access reports, I mean, there USED to be a company that offered an email function for MS Access reports. but it was called http://rptsoftware.com. I mean, I don't think that they have been online in a dozen years at least.

The whole thing about moving to Access Data Projects, and having a SQL Server Reporting Services infrastructure.. I mean, we could right click and IMPORT the report from MS Access into SSRS and since the queries were already written in MSSQL, it was SIMPLE.

I just don't like printing out the same damn report by hand every tuesday. and I wish that SSRS was as popular as it was 5-10 years ago. today, people want to be using PowerBI for this sort of thing. Drag and drop and turn it into a chart! I mean, you could look at using Tableau!

I just don't know how practical it was for someeone to move to a different platform like that. for ME, the move to SQL Server Reporting Services was FREE because it's included with SQL Server Express edition. and having the ability to write a report ONCE, and then allowing people to INTERACT with a report, I mean, reports to me. they aren't about printing static reports and then being done when you send them via PDF.. I built a LOT of interactivity in my reporting solutions for most of the last 20 years. I mean, pivottables. being able to give someone a pivot table is a MUCH better solution than reports because it allows them to 'get off your back and get your own data'.

I'm not trying to be negative. I just haven't written a static report in 20 years.
 

The_Doc_Man

Immoderate Moderator, Former MVP, Retired SysAdmin
Staff member
Local time
Yesterday, 22:41
Joined
Feb 28, 2001
Messages
17,933
As a matter of practicality, there is an old rule: Access won't tell you anything you didn't tell it first.

If you want Access to put data into a report, you have to put that data into Access first.

Add some tables and make your life easier. For privacy matters, this table should be separate from other tables even though there might be what seems to be a proper place for it in a general resident table based off a person's ID. (One man's opinion on the privacy issue!)
 

Users who are viewing this thread

Top Bottom