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, [email protected] wrote: > >> Message: 9 >> Date: Tue, 10 Aug 2010 13:17:32 -0700 >> From: Bob Sneidar <[email protected]> >> Subject: Re: revdb_connectionerr >> To: How to use Revolution <[email protected]> >> Message-ID: <[email protected]> >> 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 > [email protected] > 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 _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
