Low bandwidth Challenge from Navy Ship

[stgcs]

We are out to sea often, but the few days we are in port somewhere, we waste precious time signing out on a paper log. The goal is to have something built in Access which allows Sailors to sign out with a liberty buddy (maximum group size is five Sailors), put where they are going, and put the address of the hotel they might stay (has to be international format).

The different templates we looked at were for time cards and inventory, but could not be edited. This would new version will save a bunch of time and the queries/reports would be a big help at the end of the night when we conduct the end of day muster.

Field one is the Sailor's identifier.
Field two through field four are the Sailor's liberty buddy(ies)
Field five is the location group is going.
Field six is the hotel the group is staying (this is an if necessary field).
Capability to use simultaneously from ten computers on our LAN.
We have limited bandwidth and cannot download files (our network security is ultra high).



Thank you for your help.
Very respectfully,
STGCS

[xps35]

I hope your Navy has an IT departement

[Welshgasman]

I hope your Navy has an IT departement

No doubt they do, but if they are anything like the IT dept that was in a bank I worked for, they would consider this low priority.

I believe the O/P is looking for someone to create the system for them, which I see unlikely TBH.

We are here to help, not create systems for people. At least that is how I look at it.

If I was attempting this.

You need a split database.
I would likely ignore normalisation for the shore buddies and just have the extra fields as you have specified.
The crew entry would be combos, so you would need a crew table and their navy IDs and names.
You would need when they go ashore, and when they get back.
Have all come back? Having them as field in the Shore table would make that difficult if one got arrested, so better to have a record for each one, so would need a junction table.
You can have a check to make sure that no more than 5 are in that shore leave, so someone would need to be the shore leader, so you can check against that shore excursion and date.

So quite a lot to think about and nowhere near as simple as the O/P seems to think.
So at least 3 tables
tblCrew ' Holds all the crew details
tblShoreLeave ' Holds all the shore excursions
tblCrewShoreLeave ' Junction table linking the other two tables.

[xps35]

I said this mainly because, with 40 years of IT experience at Defense, I was surprised by the combination of ultra-high security and users who tinker with systems themselves.

It is of course clear that you need a split database and the data model is simple enough.

But does it work at low bandwidth? And how do you obtain the personal data? I don't know how many sailors there are on a vessel like that, but are you going to enter them all? And does this need also exist on other vessels?

These are all questions for professionals who know the situation.

[Micron]

My take is that the suggested design isn't normalized and I would not ignore that. A column per buddy in a shore leave party is Excel thinking, which often comes back to bite you when things change. I'd also agree - I'm here to help and we don't get any compensation for that. Developing a full blown app for free isn't within the scope of that altruism/charity or whatever you want to call it. Worst part of diving into something like this could be to find out that the ask was cross posted and you're not the only one working on something.

If an Original Poster wants to follow guidance and do the bulk of the work, then we're here to assist in whatever way we can. At least that's my take on it.

[CJ_London]

Don’t think I agree about not normalising- much more complicated to determining if a sailor is already ‘booked out’ for example

would also need to understand the process- perhaps there is one check in/out aka time card point in which case bandwidth should be immaterial. Or points all around the ship where individuals can join an existing group or create a new one for others to join

[June7]

Design is dependent on how you want to document check in/out. Either find record with the OUT and input IN on that same record, or alternative of OUT and IN on separate records (like timekeeping) and using query to "match" the record pairs.

If you look at location checking in/out crew same as person checking in/out book, the LendingLibrary template database could likely be adapted for your situation. Crew would be "assets" and location/group would be "checked out to". Mechanism for check in/out process would be same.

This is an ideal situation for use of bar code or QR scanner if ID's had these codes.

[ano]

reading the suggestions im amazed more and more
1st why need split database? just a copy download in harbour , did not read that shore need the info.
2nd why need 10 pc need access simultanious if only 5 are allowed to go shore?
3rd date/time is needed i guess or flag "on leave"
4th excel is simple gud option but after a while it get too slow
5th 1 person is responsible probably the leader or the guard on duty
6th start with empty database and have form that has all the fields needed,with check if already exist to avoid wrong spelling
7th info is only interesting during the "on leave" during harbouring so why need history
8th the paperwork is probably more fast then the database, just have a form to fill in and deliver when leave

[Welshgasman]

1. Always split data from GUI, even if one person using DB.
Then if db gets corrupted, data or gui is safe.
Divide and conquer.

[ano]

haha true but not practicle in this case if there is a lan on board a backup should be part of it and the database is mostly closed so backup is ok. if no back then backup during opening removing older then 3 versions