Stamp Collecting Access Database Program

Tikithindi, are you able to give us an update on this mighty project you started?
I am poking around in the LibreOffice database module and can get a feel for the effort involved in your Access work here.
Personally I am still using a simple spreadsheet to monitor values and inventory and an image folder to record each stamp in the collection but am starting to see the limitations looming ahead.
Does your proposal allow multiple images? (postmark extractions, back of stamp for control numbers etc. as well as just front image.)
I can keep adding to the image name to include new areas of interest to me like perforation and watermark varieties but a database seems to be a possible way forward.

Hi conker,

Happy NY and sorry to respond this after many motns or year.
due to Health many of the threads did not follow as well sayed away from net.
During these many moths or more than year I have not been able to coplete. So to say did not compile modules. Also during these years breakdown of computers and hard drives. this project got into
sort of hibernation. BTW this can be done in open office too.

thanks conker for your interest.

tikithindi

Hi Conker,
Happy holidays. One after other disaster I have encounter. Worst of
all My disks as well as computer died. Some of the Database specially.
those screen shots I posted. have been destroyed. I have started. Gathering tables from other copied versions and putting together.
Most of the tables are in place. Now working on Interface. Want to
make as such that it is easy not overwhelming. Newbee can start using
but at the same time if you want to flyspeck you have ability to do so.
You are right in Libreoffice one can do. As I have Access 2003 and 2007 am doing in Access 2007.. probably later transfer to Officelibre
or Called OpenOffice.
I have not given up Idea for Db. Though am working in Excel sheets.
keep in touch.
cheers
Edit:

this is the one screen preliminary made for Issue .. only(techdata) needed.


Most of fields are default so only few one has to mark or change if
specifications are different. This is Checkbos version.

And below is the input version.



feel free to comment or advice...
tikithindi

Tikithindi,
Obviously there are many aspects to designing a database. Not only is the underlying architecture important, but the interface itself has to be easy and flow well. And then, of course, the generated reports play an important role.

First, Access is not the best environment to head in this day and age. This project screams for a SQL backend but you need to settle on which SQL. Access is fine for a little personal database that runs on your desktop but if you want to distribute an application Access is a total pain. Too many other app have Access engine and other DLL dependencies, installing one version often steps on other versions and breaks things. Access is also a bit too proprietary to be used as a platform, it will not easily be ported to SQL or other platforms. Your store procedures and queries, for example, will not work under SQL without revisiting. Reports are a huge issue in Access. Any work you do with reports would have to be rewritten if you wanted to move to SQL. I think it is fine that you might consider the relational tables and field in a program like Access and/or Excel, but you will want to jump t something that is more flexible and portable when you go to get serious about writing the interface. I would recommend that the backend be SQL and the interface be something more like PHP.

You could then write this and have it the app run on many cross platforms since it would run in most browsers. This is an important consideration because you want to be able to support a data source which might be sitting on a remote computer somewhere. Users will not like not having this option. If you roll out with a local-only database some users will be upset, if you roll out a internet-only database some users will be upset.

Like most software, the development of it represents only a fraction of the actual work involved. Things like have a robust install routine, help file/manuals, keeping it up to date as new operating systems are released and having field support are much bigger tasks. The original development is a cake walk compared to these things. But these are the exact reasons to avoid a platform like Access and head towards something more like a SQL/PHP solution.

From a design and interface standpoint, you should have a mode which is not nearly as intimidating. Users generally do not want to face a page worth of data entry. In your desire to be complete, you are over whelming the typical stamp collector with that many fields. Using a more tabbed interface, and establishing a more basic 'first page' would help a lot. Move a lot of the other fields to other tabs which are optional. Ideally you should want the user to be able to enter the basic stamp info in less than 30 seconds.

The best interface designs are when there is nothing left to remove, not when there is nothing left to add. Think sleek, streamlined, fast. You are seeking a balance between allowing user fast and efficient data entry and completeness.

And lastly, I cannot comment on your data field types since you did not publish this info. But obviously this is of paramount importance. Far too many stamp database apps do not play attention to this and end up with all kinds of problems. A good example is the denomination field, is this a varchar, numeric, or some other field type? The field types can bite you in the butt when it comes to calculations or the import/export of data. There is also a potential to cause issues when porting to another language.

Sorry to hear that you lost data with your crash and burn. When developing you really should consider an off-site revision control solution to store your work. You are certainly tackling a huge project, one that done properly will represent many man-months of work. This is a huge investment, by yourself and by anyone who decides to use the resulting product. As such, it really behooves you to make these decisions carefully and with an eye for the future.

If you would like some help or more input, please do not hesitate to ask.
Don

Hi Don,

I am very thankful for your Input and advice. It is very informative and appropriate IMO appreciate very much. Though I did
loose my significant work loss. I had been backing many databases
Version wise so I had to find these and appropriate tables and reconstructing it.
I started this as for fun. My goal was still is if at all I can
make small database like this, it would be good for basic as well as
advance Collector ( say Philatellists )
At present Tables in 3NF or max 4 level. I want to achieve. Access to me is handy and easy way to Model Logical and Physical structure of Db. Mostly Desktop Database.
I have MySQL and fiddling around it too. Now as far as PHP concern
that is steep for me. I work on this DB and at the same time work
on Spread Sheet (with VBA ) so some atomization.
Data Type agree have to be careful consideration nice input.
Let me see how far I can run. Front End Interface at present least concern. This DB should serve as basic Inventory rather than
Catalogue. Will be in touch with you Don.

Thank you again DON.

tikithindi.