orchid database?
 

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

orchid database?
 

On Thu, 13 Oct 2005 23:25:22 GMT in C1C3f.19356$at1.6533@trnddc05 J Fortuna wrote:

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?

I currently keep a spread sheet. One "page" that tracks what I bought, when I
bought it, who I bought it from, my number for the plant. The original
vendor's number for the plant, the media it is currently potted in,
and the size of pot it's currently in.

Another that I use as a checklist for when to water, flush, fungicide...

I'm somewhat tempted to move to a "real database".
However, I've yet to even get through a gross analysis of your webmail
cgi-bin.
--
Chris Dukes
Suspicion breeds confidence -- Brazil

orchid database?
 

I keep track of the name of the orchid, from whom (or where) I bought
it, and its condition upon purchase. Quarterly, I note each orchid's
condition, top and roots. I note when I repot an orchid, its condition,
the media that I repot it in (S/H or other), when it blooms, and the
quality and number of the blooms. I note when I've won an award and the
source of the award (regional show, monthly meeting table, etc.). More
recently, I've made more notes on "outside/inside" for the summer and
where the plant is in my growing area in winter: natural light, HID
light, or flourescent light. (Alas, I do move plants around a bit--one
of the best pieces of advice I ever got was this: If it doesn't
flourish, move it.)

I also note when an orchid dies or when I've given it away. I have a
special category of "Died, Donated." Actually, the "died" category can
yield some very useful information--When I reviewed my list, I found
that ALL the orchids that I bought from a certain vendor died--Lesson:
don't buy from him again. In addition, I discovered that all my phals
seemed to have a high winter death rate in a certain growing
area--Lesson: Don't put them there again. I've discovered that the
transition from bark media to S/H is better at some times of year than
others.

No, I don't track watering because it varies so much--this week was
hot, last week wasn't, etc.

One thing that I've started doing is tracking plant divisions. What's
really interesting is to put one half in S/H and one half in bark media
and then compare their progress. For the Catt family, at first the
bark-media half does better, but after a year, the S/H half has
leap-frogged the bark-media half.

Anyway, for me, a DB has been a good way of helping me identify trends.
If I were more organized, I'd do fertilizer studies.

orchid database?
 

It seems like most people keep track of roughly the same basic data. I
do that as well, minus the watering schedule. However, my database is
not just for my orchids. I have sort of made my little own version of
Wildcatt for Phals/Dtps. I have about 1300 hybrids listed, and for each
one I have the cross and year of registration, and the species
parentage, and how much genetic material each species contributes to the
cross. I do this on Excel, as that was the only way I could see to
easily calculate genetic percentages. As for how I pick which hybrids
go in the database, I basically browse around and every once in a while
record the most commonly available orchids for sale that I see from
various vendors, and those go in.

Cheers,
Xi

OrchidKitty wrote:
I keep track of the name of the orchid, from whom (or where) I bought
it, and its condition upon purchase. Quarterly, I note each orchid's
condition, top and roots. I note when I repot an orchid, its condition,
the media that I repot it in (S/H or other), when it blooms, and the
quality and number of the blooms. I note when I've won an award and the
source of the award (regional show, monthly meeting table, etc.). More
recently, I've made more notes on "outside/inside" for the summer and
where the plant is in my growing area in winter: natural light, HID
light, or flourescent light. (Alas, I do move plants around a bit--one
of the best pieces of advice I ever got was this: If it doesn't
flourish, move it.)

I also note when an orchid dies or when I've given it away. I have a
special category of "Died, Donated." Actually, the "died" category can
yield some very useful information--When I reviewed my list, I found
that ALL the orchids that I bought from a certain vendor died--Lesson:
don't buy from him again. In addition, I discovered that all my phals
seemed to have a high winter death rate in a certain growing
area--Lesson: Don't put them there again. I've discovered that the
transition from bark media to S/H is better at some times of year than
others.

No, I don't track watering because it varies so much--this week was
hot, last week wasn't, etc.

One thing that I've started doing is tracking plant divisions. What's
really interesting is to put one half in S/H and one half in bark media
and then compare their progress. For the Catt family, at first the
bark-media half does better, but after a year, the S/H half has
leap-frogged the bark-media half.

Anyway, for me, a DB has been a good way of helping me identify trends.
If I were more organized, I'd do fertilizer studies.

orchid database?
 

"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?

Well Joanna,

While I haven't done it yet, I hope to have a prototype developed over the
next year or so, as a web application. This would be set up to include the
kind of data already described in your post and those of the other two. But
to make it really useful, I'd have a section where one can enter
morphometric data and track how the geometric description of the plant
changes through time, as well as environmental data, perhaps even supporting
mini weather stations (PAR, temperature, humidity, &c.) along with things
like potting media, or what the plant is mounted on, if it is mounted,
watering and fertilizing regimes, &c. Eventually, it may even support
genetic finger prints. The idea is to be able to support routine taxonomic
analyses, and use these to provide provisional identification of noids, and
then possibly to genetic finger prints to support such an ID.

Once I get it established, the more people who participate, and document the
culture they provide to their plants, the more likely it becomes that the
system can ID a noid. Equally importantly, or the user can visit the web
application, supply a description of their growing environment and the types
of plants they're growing, and then see the range of cultural practices that
have been tried, and with what outcome.

No Joanna, you're not weird. What you're trying to do is quite sensible.
What you include in your database is entirely up to you, and should be
determined by how you understand your present needs. There is little point
in collecting data for a given parameter if you don't know how you'll use
it. If you keep it up, it is certain that your database will evolve over
the years. It is also certain that my needs will be different from yours.
I am approaching this as an expert in decision support software who began as
an environmental scientist with a strong background in biostatistics and
numerical taxonomy. But, with the breadth of my experience in software
engineering, I can design this so it will be as useful to a secondary school
student just learning how to grow plants as it would be to a research
scientist, with each user using what he needs and ignoring the rest.

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

orchid database?
 

"?" wrote in message
rg...
Snip
However, I've yet to even get through a gross analysis of your webmail
cgi-bin.
--
Chris Dukes
Suspicion breeds confidence -- Brazil

Chris,

Ok, so if suspicion breeds confidence, am I supposed to be suspicious about
your analyzing of _my_ webmail cgi-bin, and how will that make me more
confident, and not really really concerned? Hmm.

In response to:
I currently keep a spread sheet.
snip
I'm somewhat tempted to move to a "real database".

I too started with a spreadsheet for my orchid info, and when I finally
moved to the database, I wished that I had done it a long time ago. Do think
more about it. It's definitely worth it. OrchidKitty's email shows some of
the really cool stuff that one can do with a database -- OrchidKitty, I am
really impressed! Even for less complex data, a database can be much more
organized and flexible than a spreadsheet. And the more data you have, the
more awkward the spreadsheet becomes. How many orchids do you have now,
Chris?

Joanna

orchid database?
 

Ted,
That sounds like a really interesting project. Good luck with it!
Joanna

"Ted Byers" wrote in message
...

"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?

Well Joanna,

While I haven't done it yet, I hope to have a prototype developed over the
next year or so, as a web application. This would be set up to include
the
kind of data already described in your post and those of the other two.
But
to make it really useful, I'd have a section where one can enter
morphometric data and track how the geometric description of the plant
changes through time, as well as environmental data, perhaps even
supporting
mini weather stations (PAR, temperature, humidity, &c.) along with things
like potting media, or what the plant is mounted on, if it is mounted,
watering and fertilizing regimes, &c. Eventually, it may even support
genetic finger prints. The idea is to be able to support routine
taxonomic
analyses, and use these to provide provisional identification of noids,
and
then possibly to genetic finger prints to support such an ID.

Once I get it established, the more people who participate, and document
the
culture they provide to their plants, the more likely it becomes that the
system can ID a noid. Equally importantly, or the user can visit the web
application, supply a description of their growing environment and the
types
of plants they're growing, and then see the range of cultural practices
that
have been tried, and with what outcome.

No Joanna, you're not weird. What you're trying to do is quite sensible.
What you include in your database is entirely up to you, and should be
determined by how you understand your present needs. There is little
point
in collecting data for a given parameter if you don't know how you'll use
it. If you keep it up, it is certain that your database will evolve over
the years. It is also certain that my needs will be different from yours.
I am approaching this as an expert in decision support software who began
as
an environmental scientist with a strong background in biostatistics and
numerical taxonomy. But, with the breadth of my experience in software
engineering, I can design this so it will be as useful to a secondary
school
student just learning how to grow plants as it would be to a research
scientist, with each user using what he needs and ignoring the rest.

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

orchid database?
 

J Fortuna wrote:
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 use Filemaker Pro and have a single database for all my tropicals,
including the orchids. The fields include: Family, Genus and Species,
my accession number, other accession numbers (from source, etc),
natural habitat, source of plant, date of repotting, potting material,
date of blooming, photograph, and other comments (seedling
distributions, locality/collection data, unusual characteristics, etc).

I usually keep the file sorted by Family, Genus and species, and
accession number, but Filemaker lets me search and sort by any of the
fields. It also lets me maintain the database in multiple formats.
One format contains all the fields with each plant on a separate page,
and the second is a list for quick scanning or printing that contains
only Family, Genus and Species, and accession number.

Nick

orchid database?
 

Yes Joanna, I have a data base I made using Access97 as well. I also have
"EverythingOrchid"
from our very own Pam Knapp who sometimes visits our group.
I could not imagine being without it especially with thousands of orchid
plants. I
try to keep mine updated, potting dates, divisions, culture notes etc.

http://www.pe.net/~profpam/page1.html
Pam's database is really neat & well worth the money. One feature I like for
example is
you can view a list of orchids that have bloomed in any given month.....of
course you
have to keep the bloom date updated! But I love it.
Cheers Wendy

Remove PETERPAN for email reply

J Fortuna wrote:
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

orchid database?
 

On Fri, 14 Oct 2005 02:38:41 GMT in RSE3f.24186$wm3.19828@trnddc01 J Fortuna wrote:
"?" wrote in message
rg...
Snip
However, I've yet to even get through a gross analysis of your webmail
cgi-bin.
--
Chris Dukes
Suspicion breeds confidence -- Brazil

Chris,

Ok, so if suspicion breeds confidence, am I supposed to be suspicious about
your analyzing of _my_ webmail cgi-bin, and how will that make me more
confident, and not really really concerned? Hmm.

Be very concerned and how bad my mind is munging names :-).

In response to:
I currently keep a spread sheet.
snip
I'm somewhat tempted to move to a "real database".

I too started with a spreadsheet for my orchid info, and when I finally
moved to the database, I wished that I had done it a long time ago. Do think
more about it. It's definitely worth it. OrchidKitty's email shows some of
the really cool stuff that one can do with a database -- OrchidKitty, I am
really impressed! Even for less complex data, a database can be much more
organized and flexible than a spreadsheet. And the more data you have, the
more awkward the spreadsheet becomes. How many orchids do you have now,
Chris?

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.

As for the orchids...

45 that are alive and in the sheet.
1 from the GF that is currently undergoing spag 'n bag because the GF rotted
the roots off.
3 ludisia being propagated via cuttings.
2 nobile dendrobiums being propagated from keikis.
1 ludisia propagated via cutting and given to GF.
1 ludisia propagated via cutting and sold.

We'll just not talk about the african violets, bromeliads,
spider plants, philodendrons, epihyllum, peppers, begonias ....

I refuse to worry until I'm in my 80s and one of my sprogs asks
"Just how many more ... are you going to propagate?" and I respond
"I don't know, how many more acres do I have left?"
(My granddad managed to cover a couple acres of land in South Carolina
in camelias before he died.)


--
Chris Dukes
Suspicion breeds confidence -- Brazil

orchid database?
 

"?" wrote in message
rg...
On Fri, 14 Oct 2005 02:38:41 GMT in RSE3f.24186$wm3.19828@trnddc01 J
Fortuna wrote:
"?" wrote in message
rg...
Snip

In response to:
I currently keep a spread sheet.
snip
I'm somewhat tempted to move to a "real database".

I too started with a spreadsheet for my orchid info, and when I finally
moved to the database, I wished that I had done it a long time ago. Do
think
more about it. It's definitely worth it. OrchidKitty's email shows some
of
the really cool stuff that one can do with a database -- OrchidKitty, I
am
really impressed! Even for less complex data, a database can be much more
organized and flexible than a spreadsheet. And the more data you have,
the
more awkward the spreadsheet becomes. How many orchids do you have now,
Chris?

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.

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.

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.

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

orchid database?
 

Well, it's the same, but completely different here. I have to use
a database to keep track of all the flasks in the lab, along with seeds,
seedlings, that sort of thing.

Starting from the bottom up: every batch of media has been
databased, with pull-down tabs and quantity fields for individual
components, as well as the type of container that was filled from that
batch.

Seeds are a big portion of the database; last I checked, we
stocked 450 species, and we're probably closer to 600-700 different
accessions (not individual species, mind you) at this time. All the
applicable information is databased for each accession, and then assigned
an accession number. I had to pay a programmer to do it, but now I can
upload the entire seedlist automatically with a single button click. It's
like magic, but faster.

So, when a cut of seed is sown into a container, that container is
assigned an M-number ("M" for mother flask), so that I know, for example,
M001234 has species 987 sown in it, on such-and-such a date, using X
disinfectant for Y minutes, and subjected to vacuum infiltration, or
ultrasonication, or whatever.

Then when it is replated, it gets an "R" number, so R002345 is
replated from M001234, and that batch of media in that container was made
on such-and-such a date, and I can go look up specifics on that if I want.

And then there's a section for tubes, in terms of quantity made
and quantity shipped/contaminated/destroyed, with a "difference" column so
I can tell how many came in, how many went out, and the difference (i.e.,
what should be on the shelves).

In turn, I have to have a barcode system to keep track of it all.
The mother flasks have a barcode with the M-number, the accession number,
date it was filled, and date seeds were added on it. The R-number labels
have the same data. They're printed using a Datamax M-class barcode
printer, on special labels using thermal transfer ribbon. They'll take
years of sun, as well as exposure to bleach and alcohol and friction, and
remain legible. Tubes get a simpler barcode label using a Dymo 330 label
printer (direct thermal) onto paper; they last about a year before they
start to fade under fluorescent lights. And then I have a third barcode
printer (Datamax E-class) for printing barcode labels for the seed packets
that go out; they have the name and accession number on them, with the
accession number encoded in the barcode.

Containers also get "backed up" using Sakura Ident-I-Pens, which
are paint pens (versus pigments, like Sharpie). They take bleach, alcohol,
and at least 4 years under fluorescent lights without fading; they're
archival quality.

Everything is backed up as hard copy as well as electronic copy,
which gets backed up x3 every time it's used. I think Troy Meyers backs up
every 4 hours; he uses Filemaker, I use Access. His labels for the lab
encode a bit more information on them; I prefer to have access to that
information in the database, rather than on the label. I doubt either of
us is worse for wear in doing so.

Lest anyone think I'm exaggerating or going completely overboard
by using three barcode printers, a dedicated computer, barcode scanner,
and triple secure backup- *maybe*. But I don't think so. I took paper as
far as I could go with it, and decided the longer I waited, the more
painful it would get. The transition was a complete logjam and
excruciatingly detailed in transferring to the database- but I knew the
longer I waited, the worse it would get.

Things are still backlogged, of course, but they're not as bad as
they'd be if I didn't have a database.

The address in the header isn't valud. That's why I don't return
your email.

Cheers,

-AJHicks
Chandler, AZ

orchid database?
 

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

orchid database?
 

Aaron,

It looks like you were well served by the programmer you hired. In this you
were lucky since there are many people out there who pass themselves off as
capable programmers but who are actually grossly incompetent. A great many
small businesses here have been burned so many times by such scoundrels that
they swear that they will never pay a consultant to develop custom software
ever again. And this hurts both small businesses and developers like
myself.

You certainly have not gone overboard. In fact, I am sure that if I built a
model of your business processes, I could find more things for your database
to do. One thing to consider is that as your database grows, Access will
have more trouble handling the volume of data (this is a long term
consideraton for a small business, so there is no need to worry about it
yet). I'd expect that at some point, you will find it necessary to migrate
to a more robust, and faster, database. I'd suggest MySQL because it is
free and an excellent product. And you can hire a programmer to write a
couple simple scripts to copy your data from Access to MySQL. If the
programmer is at all competent, he should be able to write the script and
complete the transfer in an hour or two. OTOH, if he is just a kid fresh
out of college, he'll likely flounder for a few days trying to figure out
what to do and how.

One of the things I am implementing over the next few months to a year is an
inventory control application that supports enterprises that have both a
virtual store and a bricks and mortar store. And of course, bar-coding will
be a vital part of the instore portion of the application.

I'd suggest you just carry on, letting your database evolve as you see more
things you can do with it that will help earn more money. I am unusual, WRT
software developers, in that I won't implement something just because I can.
Rather, I'll develop something only if a case can be made that doing it will
generate more revenue than it costs to implement it.

You could, if you wish, create a software developer's version of Rob's
rules. Beginning with, "No matter how well developed a given application
is, there are always many more features that can be built into it" (this is
known among experienced software engineers as feature creep, and it is often
the cause of the failure of software development projects).

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

orchid database?
 

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.

Then he quit his job as a programmer, languished in unemployment
for a while, and eventually ended up in the Border Patrol.

The second guy was an idiot on the East Coast.

The third fellow I found through Guru.com (or whatever it was
named before that), and I wanted a local fellow since I figured out I
couldn't very well throttle the second guy since he was in New York. The
third guy was pretty good, but he apparently got depressed about his day
job, and ended up working at a new place. Between depression and the new
workload at the new job, he kind of fell out of touch, and that was that.

The fourth fellow was another local guy; he was particularly
sharp, and did some serious work. Those of you who appreciate the new seed
ordering system can thank him for putting it together. He kind of fell out
of touch, too. He does some coding to support a trumpet habit. I think he
now does work for a major pet chain.

The most recent guy I only have doing very tiny snippets on a
per-task basis. One job at a time. He's proven to have remarkable skill,
and gotten some bits accomplished that the other guys couldn't touch. Not
quite walking on water, but close.

There were 2-3 other people in there, but none did serious work
for me. This is all over the span of about 3-1/2 years, with the first
"real" bit of work coming in at 2 years ago in December. That relieved me
of the paperwork burden of the seed list, which was wonderful. I figure
I'm at somewhere around 95% complete right now; there's still some work to
do, but until it becomes enough of a nuisance, I'm not shelling out the
big bucks to fix it.

As for moving to something else- when I got started, Access was
pretty much the gold standard for anything you wanted to run on a personal
computer to handle up to, oh, 100 megs of data, and maybe more if you were
really determined. Now, of course, I'd probably go with MySQL or something
more popular. Transferring the data over is trivial; however, re-creating
the front end would take weeks or months of my time, and more money down
the rabbit hole. The big bit would be the data entry forms, which are
remarkably sophisticated. One of the programmers re-invented the form, I
think, in doing so. But it does exactly what I asked him to do, and that's
what counts.

As it stands, many of the features I have allow me to create
wonderful lists of what I have available- and I still don't have time to
create them or dump them to the web!

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

Cheers,

-AJHicks
Chandler, AZ

orchid database?
 

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

orchid database?
 

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

orchid database?
 

"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

orchid database?
 

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

orchid database?
 

"?" 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

orchid database?
 

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