[asterisk-users] database queries from extensions.conf

Julian Lyndon-Smith asterisk at dotr.com
Mon Nov 24 12:01:56 CST 2008

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 ;)


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 

More information about the asterisk-users mailing list