revdb_connectionerr

Pierre Sahores psahores at free.fr
Wed Aug 11 12:53:15 EDT 2010


Hi Pete,

In checking the result of a db connection, each time the POST or GET command did'nt return the expected reply from the cgi or irev script, you will get directly the SQL backend debug comment in the detailed level mode as set in your db server prefs. Always very usefull, at least in using PostgreSQL.

HTH,

Pierre

Le 11 août 2010 à 18:42, Peter Haworth a écrit :

> Thanks for the replies and clarification.  I do normally check the result of each db call but came across a circumstance where revdb_connectionerr would have been useful.
> 
> I like the idea of using try/catch for all db operations and will implement that but I guess it relies on knowing what all the possible error messages can be.  Is that dependant on which sql implementation I'm using (I use sqlite).
> 
> However, that gives rise to another question.  I'm using try/catch in other places to execute rev commands that are built programmatically.  All works fine but the error messages that are caught are full of sequences of three numbers separated by commas as well as the original statement and an English error message (sorry don't have any examples immediately to hand).  Does anyone know what those numbers indicate?
> 
> Pete Haworth
> 
> 
> 
> 
> 
> 
> 
> 
> On Aug 11, 2010, at 8:12 AM, use-revolution-request at lists.runrev.com wrote:
> 
>> Message: 9
>> Date: Tue, 10 Aug 2010 13:17:32 -0700
>> From: Bob Sneidar <bobs at twft.com>
>> Subject: Re: revdb_connectionerr
>> To: How to use Revolution <use-revolution at lists.runrev.com>
>> Message-ID: <13879E4D-8EAE-45D6-95AC-25601C3DF4E3 at twft.com>
>> Content-Type: text/plain; charset=us-ascii
>> 
>> Agreed. In fact, I put all database operations inside a try/catch structure so as not to assault the end user with error dialogs that they don't know what to do with. If you are making a TON of calls in your app, you may want to consider writing a special database error function which knows how to handle all the errors you want in a way that the end user (and your app) can work with.
>> 
>> For instance, a "Database temporarily unavailable. Try again?" dialog that gives the user a chance to call IT and have them get the DB back online without dumping your app mid transaction.
>> 
>> Bob
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 

--
Pierre Sahores
mobile : (33) 6 03 95 77 70

www.woooooooords.com
www.sahores-conseil.com







More information about the use-livecode mailing list