Richard,
The design you used for your site was also my original approach in the
project I'm working on: I had a class that handled all the database
functionality of the app, and when my app needed data, I'd instantiate
an object from the class, hand it its connection data, and then call a
class method that would return the data I wanted. The database access
class would create an instance of a MySQLDatabase, connect to it, and,
on a successful connection, handle the SQL transaction, parse the data
returned as needed and return the data or an error as appropriate.
This seemed the best way to handle the database connections, rather
than keeping an open connection to the database and worrying about it
timing out or going stale. The trouble was that the app does hit the DB
regularly and frequently for both getting and setting DB data. The
crash on database.connect didn't appear during initial development and
testing, but in beta deployment, it began happening frequently enough
to be a real problem. It is one of those frustrating bugs that does not
reproduce reliably, but the logging code I put into the app confirmed
without a doubt that the crash was occurring on database.connect, and,
while the problem didn't occur exactly on the 250th connection, it
appeared more likely to occur after 200+ connections had occurred.
What I'd like to see in the MySQL plugin, though, is better error
handling of these sorts of problems - since the REALbasic database
classes have a very structured manner of usage, it seems with that
level of control over what's being passed into the plugin REALbasic
could insure failure states in the plugin don't result in a crash that
brings down the app and the IDE. I hope to REALbug both the connection
crash and the "stale" connection access crash I've seen in the near
future, but without a very reliable reproducibility, I know it'll be a
hard problem for RB to solve. But if RB's going to be targeted for
commercial enterprise usage, RB does need to provide better design
guidelines for its developers using its plugins, and try to make those
plugins rock solid. I not happy having to work around these problems
when I'm using what appears to be an acceptable design method as
documented by RB.
That said, I still appreciate all the strengths of the RD development
environment :-) - the sort of problems I've been having have been
the exception and not the rule in the course of my use of RB.
Thanks,
-Dave
On Sunday, March 30, 2003, at 05:12 AM, Richard Altenburg wrote:
For managing a jokes site (no, I am not funny at all, but my 10 year
old
daughter is) I wrote a REALbasic application that loads jokes from the
remote MySQL-database that the site is based on.
You can then click on titles of jokes, and you will get the complete
entry.
This can be jokes already on the site, and new jokes added by the
visitors.
These jokes can be edited and approved for publishing on the site.
During the management, lots of reads and writes go in and out of the
database. And it never lets us down...
What I do, is that I use my own SQL-execution method. I send every
request
through that method, which first calls the Connect-method of the
database.
If it returns True, the rest of the request can be sent and executed
by the
MySQL-system. If Connect returns False, no connection could be made,
and I
warn the user (myself or my daughter).
So in fact, for every SQL command, I try to Connect again, and it
always
works. I have never had the situation that after 250 connections or so
my
program crashed. Or didn't I ever reach that?
So I don't worry about the timeout set by the provider. And don't
depend on
them that way. It is just like a web page with PHP in it (my site uses
that): every request from a visitor is a new connection to the
database, and
it works like charm...
(setup: RB 4.5.2 on MacOS 9, MacOS 10 and Windows XP - my jokes-manager
works on all of them and is in practice used on all three)
---
A searchable archive of this list is available at:
<http://support.realsoftware.com/listarchives/search.php>
Unsubscribe:
<mailto:realbasic-nug-off at lists dot realsoftware dot com>
Subscribe to the digest:
<mailto:realbasic-nug-digest at lists dot realsoftware dot com>
.
|