Dive Log in Access Database

Please register or login

Welcome to ScubaBoard, the world's largest scuba diving community. Registration is not required to read the forums, but we encourage you to join. Joining has its benefits and enables you to participate in the discussions.

Benefits of registering include

  • Ability to post and comment on topics and discussions.
  • A Free photo gallery to share your dive photos with the world.
  • You can make this box go away

Joining is quick and easy. Log in or Register now!

I program Visual Basic for Applications (Access version) so I could probably take a stab at it. Yes, sub-forms are the way to go. As for calculating a total time, I created a quick'n'dirty database once upon a time to track my total hours worked on a contract once, and I know I got the time to total up in the form as well as the report. You can have a sub-form that updates automatically (which could slow your database down by, say 1/100th of a second or so per refresh) or have the 'update' triggered by an event such as clicking a button or moving to or from a particular field on the main form.

Pretty much anything you can do to a report, you can do to a form too. And then some.

I don't have time at the moment to look at the problem, but when I'm home and snowed in I'll pick through it.

Betcha I could make it do EITHER 8.5x11" or 5.5x8.5" pages (full or half sheet)........ that wouldn't be hard.
 
Question for the creator of the database.

I took a quick peek into the internal structure of the database. I noticed you have multiple tables but none of them reference each other, ie. there are no "relationships" set except between one humungous table (which I will have to look closer at and see if there's a way to break it up in accordance with DB Law #1) and a "dive sites" table, as well there appears to be a duplicate "dive sites1" table by itself.

Dammit, now you guys have me mentally dissecting the database...........you just know I'm gonna hafta do some work on it.

I propose that anyone who does work on this thing, when you re post the newest version, assign it a version number. eg. Dive Log v2.0, 2.1 etc. Otherwise we'll never keep track of whose was done when. It could get messy.

PS. Only when you have a proper structure set up including table relationships, will neat-o features like drop downs and table cross-references work properly.
 
Hey freefloat,
I just took a shot at it one day, very limited knowledge of Access. Then others joined in and it grew from there. I do like the idea of assigning a version # though. Any changes you can make to improve on this would be great!!!

Later,
Coz
 
Freefloat,

Blame the one huge table on me. I knew better than to do it that way, but couldn't get the relationships to work out right. Sort of rusty on my skills. I like the idea of numbering the versions also. Thanks for pulling me into the 19th century and I look forward to seeing what you can do with this log book. Feel free to split up the tables and establish relationships. I just sort of added and added and added to the one table as things came to my mind. No telling where we can do with it from here. Looks like you may get the snow break to work on it.

Merry Christmas to all,

McMag21
 
Although you can't do calculations in a table, you can in a query.
In the attached example length and width are the only data values in table1.
Area comes into being in query1. The form is then based on the query and not the table.
 
If you want to accumulate a total of some value present in each dive, you will need to restructure your data. The diving day(DD) becomes the top table ( the 1) and dives(D) is the (many) relationship. The main form’s source is the DD and the sub forms is the D table.

The enclosed example demonstrates.

Chuck
 
I have a suunto dive computer and would like to link the .csv file to the database so I wouldn't have to reenter all my dive times and depths. However I haven't figured out which field is what with the csv data.
 

Back
Top Bottom