Computer Program Advice required

[Specky]

This may be a little bit random, and not being to computer savvy, I could do with a little advice and help please.

I'm currently working on a research project which is collating information on just over a 1000 men who were assigned to a single Army unit created in 1913-14.

What I would like to do is.... have a search screen where the operator could enter details such as Service Number or name, this would either return a "hit" or not...

It would then take the operator to a new page about said soldier.

This screen would have a menu and some other pertinent information... e.g.

Photographs
Attestation Paperwork
Copies of the Medal Rolls
Copies of Medal index card
Other pertinent data etc...

So my Question is this, what would bethe best way to create such a document which the operator can keep drilling down for information?

I'm thinking an Excel document... with a lot of hyperlinks, but this seems a little time consuming.

I'd even be open to something which could work on an IPad etc...

Any advice creatfully received...

TIA

TTFN

[Giniw]

Hello,
I you want to stick to an MS Office application I think I would maybe try to do it with Access and its forms abilities. (https://support.office.com/en-us/articl ... 7e21e80c6b)
How are organized your data?

[Specky]

I haven't organised or compiled it yet...

I know where all the information is... It's spread over the internet... or in my head... that's why I thought I'd ask before I started.

I've used an access database once... we had an "electronic form" which we developed and was filled in by the end user...

We could email the form off from just one press of a button on the form, it would allow interaction from other users..you could see a history of amendment...

I guess I could look at Microsoft Access.... I thought there was major security issues with Access...

[Specky]

I've reviewed the hyperlink... and that seems to be just the ticket.

It looks a bit daunting, so I'll do an online course at work and see how things go.

Many thanks

TTFN

[dapinky]

Speckster,

There are many systems out there which will 'do the job' off the shelf, but Access is the one which will be easiest for you to get your head round (mainly because it is part of the MS Office suite and as such is supported by most business systems).

As you already use Word, Excell, Outlook etc, it *should* be fairly easy to become accustomed to.....

[Saltire]

Hi Specky

Access is the 'standard' answer, and would work OK. However, it's quite complicated, and not easy for a beginner to get to grips with. You might also like to consider OpenOffice Base or Obvibase. OOBase is a bit Marmite (people love it or hate it), but it's comprehensive and free. Obvibase is also free, but simpler. It has some size restrictions, but given your expected volumes, that shouldn't be a problem. The other thing about Obvibase which may be useful is that it integrates well with external products like Dropbox, and the data import/export works well.

Looking at your description of what you want to do, 1,000 records is a small database, so no problems there. The search is straightforward, as is the drill-down. The area which might be a bit more of a challenge is integrating the images (medal rolls, photos, etc). What I might do is scan those and store them externally to the database, with a hyperlink to display them. Would need to know a bit more about the application first though.

My best advice would be to give one or more a try and see what floats your boat. Sounds an interesting project! Good luck and let us know how you get on.

[Giniw]

I don't really know if that would be hard for someone who is not too used to do that sort of things, but I suppose one can find a lot of tutorials though.
As for the images, I would store them directly in the database.
Assuming a soldier can have zero, one or more attachment and that an attachment belongs to one soldier (and only one), the basic idea is that you would have a Soldier table and an attachment table.

Code: Select all

Soldiers table description:
id (primary key auto increment), first name, lastname, service_number, etc.

Code: Select all

attachments table description:
id (primary key auto increment), soldier_foreign_key, attachment_name, attachment_binary_data, attachment_type, etc

Example for a two soldiers table:

Code: Select all

soldier:
0, John, Doe, 123456, etc
1, Foo, Bar, 456789, etc


Code: Select all

attachments:
0, 0, "Attestation Paperwork", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
1, 0, "Copies of the Medal Roll #1", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
2, 0, "Copies of the Medal Roll #2", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
3, 0, "Copies of the Medal Roll #3", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
4, 0, "Attestation Paperwork", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
5, 0, "Other Paperwork", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
6, 1, "Attestation Paperwork", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc
7, 1, "Copies of Medal index card", xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, "image/jpg", etc

(xxxxxxx represents here the binary data, just don't pay attention to that)


Remember the first column of the attachment table is just a unique ID for each table records (each line), here it doesn't serve any purpose for the attachment table.
The second column is a foreign key referring to the soldier table unique IDs.
See, the first attachment batch from 0 to 5 belong to John Doe who has the 0 id in the table soldier.
And of course, the last two attachment (6-7) belong to Foo Bar.

Now that you get the idea, the SQL (structured query language) to retrieve the attachments from a soldier would be as simple as the following:

Code: Select all

SELECT * FROM attachments WHERE soldier_foreign_key=0;

(or soldier_foreign_key=1 if you want the attachments belonging to the soldier 1 who is Foo Bar, etc)

I don't know if that makes sense to you but I hope if helps a bit!
(I think access tends to (try to) hide those details but I am not too sure so don't worry too much)

[Brit-Car-Nut]

I used to do a lot of that type of programming in the DOS/early Windows days using Clipper but that won't work in the new operating systems. It was "top - down" programming that was compiled when finished and was very fast.

I would do it using related databases to keep the data storage as small as possible. A common pointer in each record would be used to marry the data once a record was found.

My MG parts database had over 17,000 part numbers across 25 different suppliers and I could search a part number or description quickly and then see all of the extra details by just hitting a function key.

This allowed me to keep the basic info - part number and price in one database, the description and other notes in a different database. The description, model application and such was fairly detailed, so for 15 interchange part numbers, I only had to keep that info in one record.

Most Internet parts/inventory programs/databases these days are now coded in sequel because it handles relationships efficiently and reports are easier to code.

VB and Access can do it too but not efficiently as they are really just flat files with a lot of fields.

[Saltire]

I used to do a lot of that type of programming in the DOS/early Windows days using Clipper but that won't work in the new operating systems. It was "top - down" programming that was compiled when finished and was very fast.

Ah, Clipper! <strokes long white beard> Wonderful programming environment that IMHO has never been beaten for straightforward database building and coding. If only it had continued to evolve into the Windows era . . .

VB and Access can do it too but not efficiently as they are really just flat files with a lot of fields.

Absolutely; I'm sorry to say another example of Microsoft cobbling something together in a hurry rather than thinking about the problem and coming up with an elegant solution . . . <rant mode = OFF>

Now, what cars can I think of that adopted the same design approach . . . . . ?

[dapinky]

All you bloody dinosaurs, talking about stuff which will NEVER be relevant again are not helping Mr Speck at all.....

I can see him now, looking at the screen and thinking "What the f**k - I wanted a simple system.....maybe I'll stick in in a spreadsheet!"


....oh, and from the info in the above few posts, I am now a bit worried about my plan for World Domination....

.... I had always thought that come the glorious day that the Electricity Supply goes wrong, and the UK grinds to a halt, there would be no-one left alive who understands the computer language used in the National Grid.....

..... but now, I think that there may still be a few who would be able to work with the adapted version of COBAL which is used (and it is the only known use of it anywhere in the world - unless you know different) - bugger