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: 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 > -- Atis Lezdins, VoIP Project Manager / Developer, IQ Labs Inc, [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Cell Phone: +1 800 7300689 Work phone: +1 800 7502835 _______________________________________________ -- 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