Collection software

It occurred to me that I might want to consider some sort of software
solution to keeping track of my collection. I have seen a few packages
out there ranging from $20 to $300, but:
1) Being relatively new to this,
2) Being a Linux user, and
3) Being a glutton for punishment,
I thought I might develop my own solution.

However, since I *am* relatively new to philately (at least since about
1978 or so), I am not sure of the sort of things I'll want to include.
I know that at least part of this will be determined by my plans for the
collection, but I am ignorant of much of this. So far, I was thinking of:

Year of issue
Scott Catalog number
Denomination
Subject/title
Status and condition (mint/used, excellent/good/fair/poor)
Perf
Type (single, part of an attached set, etc)
Special (notes, plate block, etc)

It might be nice to add an image of the stamp in the collection, as well
as date added to collection. Unless I'm missing something, this should
be relatively easy to knock out. Any thoughts on this?

Thanks in advance,
-Don Levey

On 8/31/2010 11:37 AM, Don Levey wrote:
It occurred to me that I might want to consider some sort of software
solution to keeping track of my collection. I have seen a few packages
out there ranging from $20 to $300, but:
1) Being relatively new to this,
2) Being a Linux user, and
3) Being a glutton for punishment,
I thought I might develop my own solution.

However, since I *am* relatively new to philately (at least since about
1978 or so), I am not sure of the sort of things I'll want to include.
I know that at least part of this will be determined by my plans for the
collection, but I am ignorant of much of this. So far, I was thinking of:

Year of issue
Scott Catalog number
Denomination
Subject/title
Status and condition (mint/used, excellent/good/fair/poor)
Perf
Type (single, part of an attached set, etc)
Special (notes, plate block, etc)

It might be nice to add an image of the stamp in the collection, as well
as date added to collection. Unless I'm missing something, this should
be relatively easy to knock out. Any thoughts on this?

Thanks in advance,
-Don Levey

I'm not a Linux user, but you should be able to set up an OpenOffice.org
Calc spreadsheet to keep track of your stamps. You can insert a stamp
picture and anchor it to a cell, if desired. It is probably better to
insert a hyperlink to an external image, though.

Bill

On 8/31/2010 15:58, Billns wrote:


I'm not a Linux user, but you should be able to set up an OpenOffice.org
Calc spreadsheet to keep track of your stamps. You can insert a stamp
picture and anchor it to a cell, if desired. It is probably better to
insert a hyperlink to an external image, though.


Bill, that's an interesting thought. My original plan was to store the
data directly in a MySQL database, which would allow me some flexibility
in reporting, querying, and the like. It would also give me the
opportunity to create the front end in php, which would mean I could
access it from elsewhere if necessary.

-Don

On 8/31/2010 1:11 PM, Don Levey wrote:
On 8/31/2010 15:58, Billns wrote:


I'm not a Linux user, but you should be able to set up an OpenOffice.org
Calc spreadsheet to keep track of your stamps. You can insert a stamp
picture and anchor it to a cell, if desired. It is probably better to
insert a hyperlink to an external image, though.


Bill, that's an interesting thought. My original plan was to store the
data directly in a MySQL database, which would allow me some flexibility
in reporting, querying, and the like. It would also give me the
opportunity to create the front end in php, which would mean I could
access it from elsewhere if necessary.

-Don
Don
If you're going to use a MySQL database you might want to look at the
Base component of OpenOffice.

Be sure you're using version 3.2.0 or better, as Base has been
significantly improved in recent OOo versions.

Bill

On 8/31/2010 16:23, Billns wrote:

Don
If you're going to use a MySQL database you might want to look at the
Base component of OpenOffice.

Bill,
I'll admit that I'm not that familiar with OO-Base. Do you know if php
has access to it? One reason for my initial choices, frankly, is that
I've got some experience with them, but I'm happy to learn.

Be sure you're using version 3.2.0 or better, as Base has been
significantly improved in recent OOo versions.

I believe I'm as up-to-date as possible, given my repositories (CentOS
for the server, Fedora for the clients), and all should be at 3.2.
-Don

Hi Don,

My preference would be a MySQL database. Using hyperlinks is alright
but if one moves the images somewhere elese you might have to reset
the hyperlinks. I am not sure how OpenOffice handles hyperlinks.

With MySQL any type of report generation should be relatively fast and
easy ( based on my knowledge of Mainframe SQL ).

Jerry B

On 8/31/2010 1:35 PM, Don Levey wrote:
On 8/31/2010 16:23, Billns wrote:

Don
If you're going to use a MySQL database you might want to look at the
Base component of OpenOffice.

Bill,
I'll admit that I'm not that familiar with OO-Base. Do you know if php
has access to it? One reason for my initial choices, frankly, is that
I've got some experience with them, but I'm happy to learn.

Be sure you're using version 3.2.0 or better, as Base has been
significantly improved in recent OOo versions.

I believe I'm as up-to-date as possible, given my repositories (CentOS
for the server, Fedora for the clients), and all should be at 3.2.
-Don


Don
Here's a negative quote from a forum post I found by searching for "php
and openoffice.org." It's from 2008. And the newest "Getting Started
with Base" PDF doesn't even mention php.

Base maintains its files in an Open Document Format (which basically a
ZIPped bunched of XML files and attachements) , where ODF is used for
the reports, forms, etc. The database itself is stored inside the ODF
container as a binary attachment. The actual D/B engine is the Java
based database HSQL; The D/Bs binary format is just the native HSQL format.

Architecturally this has a lot of limitations compared to a conventional
database. First, you need to think of an ODB file as a document which
embeds a database, rather than a database which embeds meta objects to
present it (as in access). Manipulating an ODB database involves
unzipping the entire D/B, manipulating it then zipping it up again to
save it. This approach does not scale well. Also, the HSQL engine is
basically a bunch of java classes which present a JDBC interface.

I could go on but the short answer is really no, you can't easily
integrate Base into php with ODBC.

Bill

On 8/31/2010 18:00, Billns wrote:
...
I could go on but the short answer is really no, you can't easily
integrate Base into php with ODBC.


Bill,
Thanks for that - it looks like the technology choice for me is clear.
Any thoughts on the features I'm looking for?
-Don

On 8/31/2010 3:09 PM, Don Levey wrote:
On 8/31/2010 18:00, Billns wrote:
...
I could go on but the short answer is really no, you can't easily
integrate Base into php with ODBC.


Bill,
Thanks for that - it looks like the technology choice for me is clear.
Any thoughts on the features I'm looking for?
-Don

I'd leave perforations off the field list. The catalog number includes
this and most (certainly not all) modern issues only come one way.

Bill

On 8/31/2010 20:15, Billns wrote:
On 8/31/2010 3:09 PM, Don Levey wrote:
On 8/31/2010 18:00, Billns wrote:
... I could go on but the short answer is really no, you can't
easily integrate Base into php with ODBC.


Bill, Thanks for that - it looks like the technology choice for me
is clear. Any thoughts on the features I'm looking for? -Don

I'd leave perforations off the field list. The catalog number
includes this and most (certainly not all) modern issues only come
one way.

OK. The main reason I was thinking of it was for instances where I am
unsure of the catalog number, Then again, I need to get myself the
catalog...

-Don