Hi Trevor,
Thanks for taking the time out to reply.
A couple of things to address here.
Creating the database
The recipes.rev file assumes that you have already created the
recipes table in your MySQL database. That is what the recipes.sql
file is for. I did a search on google on the phrase "import sql
into mysql" and there were some useful results. Some people
mentioned some MySQL database editors you could download. Those
will have the ability to import a sql file through a menu option.
In CocoaMySQL it is File->Import->CocoaMySQL dump.
Ok, that's great, but I don't have any database to import, I want to
create a new one from scratch. Is there anyway to do this using
libDatabase (with either Version 2 or 1) ?
libDatabase 2.0
The recipes.rev stack will not work with libDatabase 2.x as there
were some changes to the API which made the two incompatible.
libDatabase 2.x is marked as beta mainly because I haven't had time
to put together example stacks, etc. If you use the recipes.rev
stack with libDatabase 1.x and understand the concepts then
switching to libDatabase 2.x in your project should be very easy.
Ok, I understand now, thanks. One question, will libDatabase 1.x work
with the version "MySQL" that I have already installed?
I have now looked that three database solutions and none of them
seem to work and there seems to be very little "getting-started"
information supplied with them.
libDatabase does work, it just doesn't have any good introduction
to databases documentation/examples with it. I believe the Getting
Started guide that comes with libDatabase 2.x contains enough
information for someone who has a solid understanding of both
Revolution and SQL databases. If you are new to databases then you
may have difficulties because there isn't an "Introduction to SQL
Databases and Revolution using libDatabase" article. I would love
to write one someday but I don't know when that will happen.
Also, I highly recommend using version 2 of the libDatabase
library (available from the same page as version 1). Version 2
does not have an example stack but there is a getting started doc
which describes the differences between version 1 and 2 along
with code explaining the main functionality.
All I want is a simple database in order to build a prototype
application to take to a prospective client and try to convince
them to buy into the project.
I need to store and retrieve via the following fields:
Name | Type | Size | ImageFilePathName
I have a CD with around 200,000 objects on it that I want to enter
into the database.
I don't want to lay out a lot of money at this stage nor do I want
to have a massive learning curve to get it working. If I get the
go ahead on the project then the database will be extended, a run
time license purchased and I will of course be prepared to invest
a lot of time learning about it. But right now, time is of the
essence and I just want to get something up and running ASAP!
I don't know that you can get around a learning curve given the
current state of things, even to just have the 4 fields that you
desire. Given that time is of the essence and this seems to be a
prototype I would bypass SQL altogether. Just use a card database
to store the information (do you need all 200,000 records for the
prototype?) and show proof of concept. If you get the go ahead
then you can learn about SQL databases and implement one in your
project. SQL is an incredibly powerful way to manage your data so
it is definitely worth learning about IMO.
I tried that already! They like what they see as implemented as a
Card Database. An SQL database is the main feature of the app and
something that I said (maybe by mistake) would be no problem under
RunRev. The rest of the app I coded really quickly and have it
working just fine, now all they want is to see it working with an SQL
database. They will use the SQL database with other applications, not
just the one I am working on.
All my Stack needs to do is:
1. Create the Database.
I have a list of image files in a folder, the name field is the name
of the file, the Type and Size fields are determined by looking up
the name in a text file and the path is just the local path to the
image file. This operation can (and will be slow) but this is
acceptable since it will only be performed once.
2. Retrieve from the Database.
The user enters a name, the record with this name is returned.
Is this really a massive learning curve? I have until Monday to get
this and some other purely RunRev stuff working, surely that's enough
time to do this?
Thanks again
All the Best
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
