Atis Lezdins wrote: > On Mon, Nov 24, 2008 at 8:01 PM, Julian Lyndon-Smith <[EMAIL PROTECTED]> > wrote: > >> For me, the "best" is the curl function, along with res_config_curl. >> Best of all worlds - pass a web query to *whatever* backend system you >> want to implement. No messy ODBC drivers. >> >> It's really, really good stuff ;) >> > > However you probably can't use it for transactions within call > workflow. For example: > > Yeah, you are right. However, I would never want a transaction to span user interaction. Yeuch.
Gather, verify, process. Done. Customer Calls in Record inbound call details. Play prompt A Record further details Play prompt B Record further details We tie these three discrete transactions together by a guid. Julian > Customer calls in > Start transaction > Do query 1 > Play prompt A > Do query 2 > Play prompt B > Do query 3 > End transaction > > So, if customer hangs up in middle, you don't execute transaction. > That's the thing how it should be done with ODBC or whatever :) > > Regards, > Atis > > > > >> Julian. >> >> Jared Smith wrote: >> >>> On Sun, 2008-11-23 at 00:47 -0500, Al Baker wrote: >>> >>> >>>> Quote " >>>> The preferred method is to use func_odbc, which takes SQL queries and >>>> builds custom dialplan functions from them. I've used it quite a bit, >>>> >>>> and am very happy with it." >>>> >>>> How can you be VERY HappY with something that allows ONLY single statemts >>>> of SQL >>>> >>>> >>> My intention here is not to start a flamewar over which one is *best*, >>> or worse to start arguing about who is right instead of what is right. >>> You're absolutely correct in your assertion that func_odbc doesn't >>> currently support multi-statement or transactional statements, which is >>> obviously a limitation to some people. As I pointed out in my other >>> response to this thread this morning, Tilghman Lesher is working on >>> that. Feel free to look at his odbc_tx_support branch on the web at >>> http://svn.digium.com/view/asterisk/team/tilghman/odbc_tx_support/, or >>> to check it out via Subversion at >>> http://svn.digium.com/svn/asterisk/team/tilghman/odbc_tx_support/ >>> >>> One other way of working around the problem is to use stored procedures >>> in the database. >>> >>> That being said, I guess I'll articulate my own personal reasons for >>> preferring func_odbc, and leave it at that. >>> >>> 1) I like that my dialplan isn't tied to one particular database. I've >>> done a *lot* of database work in my short career, including being a >>> sysadmin for one of the largest MySQL database installations in the >>> world. I *love* the fact that the ODBC abstraction layer means I can >>> easily change my backend database from MySQL to PostgreSQL (or Oracle or >>> SQL Server, heaven forbid!) at the drop of a hat. I realize that might >>> not be a big attraction for some, but for me it's a big plus. >>> >>> 2) I don't like the licensing mess associated with linking MySQL >>> directly to Asterisk. I'm sure there are a few people on the list that >>> really enjoy the convoluted logic of tip-toeing the licensing minefield >>> of linking (dual-licensed) Asterisk with (dial-licensed) MySQL, but I >>> prefer to avoid the minefield altogether and use ODBC. >>> >>> >>> >>> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> _______________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-users mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-users >> >> > > > > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users