Open Office does have a database, called (cleverly enough) BASE:

http://www.openoffice.org/product2/base.html

It apparently supports MS Access databases natively. I have yet to
try it. I've been using Open Office suite for a couple of months now; the
1.1.5 version has been remarkably useful. My third book is being written
in it as something of an experiment; the drawing program allows me to
create sketches and then insert them into the document. Now at 124 pages,
and not even 150 kilobytes in size- which given the stuff I've jammed in
there isn't too bad.

For those of you not aware, Open Office has a word processor, a
spreadsheet, a drawing program, and other goodies- for free. It can take
Microsoft files, and an upcoming release is expected to build
substantially on the existing version. Highly recommended.

http://www.openoffice.org

(It's free as in beer. Very nice.)

The email address in the header doesn't work. That's why I don't
reply to your emails.

-AJHicks
Chandler, AZ

I use MS Access also. But I have 856 entries and I don't think I could
handle watering the way you do. I do have fields comparable to yours. I have
added additional fields for hlinks to pics. The main queries I've set up are
for inventory purposes (how many, what sizes) both for sale purposes as well
as to take along when I'm out for purchases to prevent dupes, etc.
Gary
"J Fortuna" wrote in message
news:C1C3f.19356$at1.6533@trnddc05...
I was wondering how many people here have a database for keeping track of
your orchids, and if you do what kind of info do you store in your
database?

I have a database that I created in MS Access in August 2004 and have been
using since then. In this database I store information such as: official
name of plant, my own nickname for each orchid, genus, whether it is a
species or hybrid, date acquired and vendor acquired from, comments,
spiking/blooming/wilting dates (whenever I remember to log them or
approximate dates when I do not), and also watering dates with average
watering interval calculated. I run a query every morning which tells me
which orchids most likely will need to be watered on that day, and then I
check these orchids first and water them if needed and if I have time then
I
check the ones scheduled for the following day or two to check whether
they
need watering early. I log the date watered in the database immediately
after the watering, so that I continue to keep track. I also have a query
showing me a list of orchids that are currently in bloom and since when,
and
all the ones that are currently in spike and since when.

Anyone else track watering schedules in a database, or am I weird in that
respect?

What other info do you track? I know I should probably add fields to my
database to track the date each orchid was last repotted, any other info
that it would be useful to track?

Joanna

"Aaron Hicks" wrote in message
...
Actually, I did the bulk of the work. I had to hire out
programmers to do bits and pieces that used VB that was above my own skill
level. The first one to do work was the one who suggested I put all my
stuff in a database to begin with. His comment, upon seeing the paperwork
system I had, was that it was the "most organized" system he had ever
seen. For a guy like me whose typical organizational system consists
largely of piles and knowing which square meter of the floor something
might be on, I suppose that says something.

Actually, that says a great deal. I think, now that I have seen the history
of your project, the success of the project has more to do with your skills
than the abilities of the programmers you've hired. Yes, one or two of them
proved to be somewhat useful, but I have a problem with programmers that
choose not to finish what they have started. In my view, that is entirely
unethical. The excuses they offer are irrelevant. If they encounter
personal or professional problems, they ought to have enough self discipline
to finish regardless, and solve their problems on their own time.

Since you seem most concerned about your GUI, might I suggest you take up a
hobby of programming in java. You have a resource in me, should you run
into trouble. You can download NetBeans with Sun's Java SDK from either the
NetBeans site (www.netbeans.org) or Sun's site (developers.sun.com). I
suggest this because Sun provides outstanding tutorials on Java programming,
including database programming, and NetBeans provides an outstanding form
editor. I am certain that if you can handle MS Access development, you can
easily handle Java programming using NetBeans with the Java SDK. And, if
you can become proficient in something through independant study, I can help
you solve the ocassional problem should you get stuck. If you do this,
you'll have the skills you need to upgrade your application yourself, and
you won't need to rely on hiring someone else to get the job done. Or, if
you must hire someone because you don't have the time, you can closely
supervise him or her, and do weekly, or even daily code reviews to ensure
the quality of the work.

With regard to migrating your application over to MySQL, that would be
simple if your GUI was properly designed and implemented, especially if
written in Java. Alas, anything written in VB is going to be a royal pain
to maintain, not to mention upgrade. I could bore you with why I don't much
like VB, but this isn't the place.

Cheers,

Ted


--
R.E. (Ted) Byers, Ph.D., Ed.D.
R & D Decision Support Solutions
http://www.randddecisionsupportsolutions.com/
Healthy Living Through Informed Decision Making

On Fri, 14 Oct 2005 15:22:20 -0400 in Ted Byers wrote:

I agree that databases tend to work much better than spread sheets.
However, databases cannot be maintained for weeks on end with a printout
and a pencil or pen :-).
Moving to a database has been hindered by laziness and cheapness.
Open Office currently lacks something equivalent to access and rolling
my own database is going to lead to a tangent on generating tables for
printout and attempt #3 at writing a GUI app.

Well, you coud try MySQL. It is free, and if you get the administration app
available for it, creating new tables is as easy as it is in MS Access. I
have worked with both. MySQL is, though, a more serious, production quality
DB and so, for ease of entering data, and then viewing it, you'd need to
create a GUI App. You say you've tried to create a GUI App a couple times.
May I ask using what, and in what programming language? It is quite easy,
now, to create GUI applications using products like NetBeans (free from
www.netbeans.org) and Suns Java SDK (free from Sun). It is hard to beat
free. If you want to give it a try, using NetBeans and Java, and you get
stuck, just ask and I'll try to help you. But since I try to earn a living
doing this, I can't guarantee an instantaneous response. A terrific
resource for you are those Usenet newsgroups focussed on computer
programming, but again patience is sometimes required.

I'm familiar with mysql (In fact it has become a somewhat important
part of my current job). I tend to keep away from Java. With the
appropriate libraries seems to be a decent, if slow, tool for providing
user interfaces. It seems to be wholly inadequate for data processing.
I'm old school C/sed/awk/perl/DB2 SQL including implementing state machine
parsers in perl and awk.

The first attempt, which was successful, was a problem tracking
application done in REXX with one of the GUI toolkits for REXX
in the early 90s (DB2 was the backend for the data).
The second attempt was a connect four game in Visual Age Small Talk.
I'm afraid that my viewpoint on object oriented programming was
indelibly tainted by someone more focused on the method than
the result.
It doesn't help that I'm one of those folks that doesn't see an issue
with inflicting an obscure positional grammar onto end users :-).

The fact is that spreadsheets are modelling tools, wholly inappropriate for
trying to maintain a database. But it is tempting to abuse them in this way
because it is so easy to use them to manage data. Using a spreadsheet to
manage data, though, is rather like using a hammer to drive a screw. You
can do it, but doing so is usually harder, and always less efficient, than
using the right tool, and it will eventually lead to significant problems.

In this case a spread sheet is a substitute for graph paper that is
less likely to be water damaged :-).
(Except it still gets water damaged because I work from printouts.)

I'd wager that Open Office doesn't have something like MS Access largely
because there are several open source DB products including, but not limited
to, MySQL and postgres.

When I say "Access" I really mean something like QMF and that
horrid GUI forms tool for DB2/2 from a decade past.
From what I've seen of Access is that it provides a more up to date
implementation of such functionality. However I'm not entirely
certain as it's almost always interfacing to the most braindead
database schema I've ever seen :-).


--
Chris Dukes
Suspicion breeds confidence -- Brazil

"?" wrote in message
rg...
On Fri, 14 Oct 2005 15:22:20 -0400 in
Ted Byers wrote:

[snip]
I'm familiar with mysql (In fact it has become a somewhat important
part of my current job). I tend to keep away from Java. With the
appropriate libraries seems to be a decent, if slow, tool for providing
user interfaces. It seems to be wholly inadequate for data processing.
I'm old school C/sed/awk/perl/DB2 SQL including implementing state machine
parsers in perl and awk.

I understand completely. My first programs were written two and a half
decades ago in fortran on punch cards. Remember those?

My first preference for programming is C++, but I find java today provides
decent performance. Sun has come a long way with it, even though their
support for generic programming is severely crippled. It used to be as slow
as molasses in January, but now it s reasonable. It isn't nearly as fast as
a binary produced by a good C++ compiler, but it is adequate for the problem
domains I use it for.

The first attempt, which was successful, was a problem tracking
application done in REXX with one of the GUI toolkits for REXX
in the early 90s (DB2 was the backend for the data).
The second attempt was a connect four game in Visual Age Small Talk.
I'm afraid that my viewpoint on object oriented programming was
indelibly tainted by someone more focused on the method than
the result.
It doesn't help that I'm one of those folks that doesn't see an issue
with inflicting an obscure positional grammar onto end users :-).

In this case, if we're talking professional software development, we'd be at
odds. I have never had a software project fail and a large reason for this
is that I take the user's needs and desires into account, producing an
interface that is intuitive and very easy to use, even if the user's skill
level is that he can only turn the computer on and use a word processor as a
glorified typewriter.


The fact is that spreadsheets are modelling tools, wholly inappropriate
for
trying to maintain a database. But it is tempting to abuse them in this
way
because it is so easy to use them to manage data. Using a spreadsheet to
manage data, though, is rather like using a hammer to drive a screw. You
can do it, but doing so is usually harder, and always less efficient,
than
using the right tool, and it will eventually lead to significant
problems.

In this case a spread sheet is a substitute for graph paper that is
less likely to be water damaged :-).
(Except it still gets water damaged because I work from printouts.)
I have seen whole computers fried because somebody spilled water on a
spreadsheet. ;-) Computers and water don't mix with good results.

My M.Sc. supervisor never used a text editor. Instead, he would write out
programs on paper, and I would have to enter them, and then debug them, for
him. And this was not that long ago.

I'd wager that Open Office doesn't have something like MS Access largely
because there are several open source DB products including, but not
limited
to, MySQL and postgres.

I have been corrected. Open Office does have a database called base. So
that means there is even less reason to use a spreadsheet. ;-)


When I say "Access" I really mean something like QMF and that
horrid GUI forms tool for DB2/2 from a decade past.
From what I've seen of Access is that it provides a more up to date
implementation of such functionality. However I'm not entirely
certain as it's almost always interfacing to the most braindead
database schema I've ever seen :-).

MS Access is a very good product, and quite appropriate in many contexts.
In some cases, I wowuld, and in fact have, used it. However, for most of
what I find myself doing lately, I have to use something more pwerful, such
as MySQL.

Cheers,

Ted


--
R.E. (Ted) Byers, Ph.D., Ed.D.
R & D Decision Support Solutions
http://www.randddecisionsupportsolutions.com/
Healthy Living Through Informed Decision Making

On Fri, 14 Oct 2005 15:33:35 -0400, "Diana Kulaga"
wrote:

I'm still using a spreadsheet, but it's getting unwieldy. As far as data, I
keep pretty much what all of the other posters do, sans the watering
schedule. There are too many variables to consider in my case, growing
outside.

I do add a hyperlink for each plant so I can know what each looks like.
Naturally, there are lots of plants that I can picture in my mind, but with
250 or so, it's easy to forget what some hybrids look like.

Diana

We use Access but don't put in repot or bloom data - never
remembered to up date it anyway. We have a check box for the
photo or not and if it is checked I can look at the web site for
the date the pix was taken. Since we only photograph in bloom
and early in the cycle - it gives me a date at which to expect
blooms. We recently added a barcode for each pot. So that we
can get a more accurate inventory. Loosing plants or buying
duplicates without having it on the database bothered me.

We carry a version of the list on the pda while we shop. ThinkDB
is the pda application that takes the access file and condenses
it for pda use.




SuE
http://orchids.legolas.org/gallery/albums.php