ODBC support in Trixbox
Submitted by jgleim on Thu, 04/03/2008 - 2:24pm.
Please, please, please could the Trixbox CE team consider building Asterisk with ODBC support included? A default Trix CE installation already includes the unixODBC package which is the underlying requirement. It seems just that Asterisk needs to detect it and include the module when it is built. (This is how I got it to work)
I'm sure there are a number of users out there like me that need to store CDRs or VMs or something else in an external database and it is a serious pain to make it work. Then, as I found the hard way, if you update your system, it breaks. If this was part of the package we would have a lot of freedom when it came to database stuff.
What do you think? Is this a possibility for the next rev?
Although I have no issues
Tue, 04/15/2008 - 5:06am
Although I have no issues accessing the MySql data because of my familiarity with programming and MySql, this could reduce the need for integration programming for users that my not have the skill sets to access to data easily. Now someone with Excel/Access/Crystal Reports ODBC data skills could get the data and massage it how ever they like.
The decision to add feature shouldn't always be tied the number of requests. Sometimes vision of feature use should trump the number of requests.
Support for external DB would be nice
Tue, 04/15/2008 - 6:29am
Kerry,
Thanks for following-up and hopefully opening a dialog on this.
And thanks to James for his insight. I totally agree with you that this support may ease DB access for people unfamiliar with MySQL.
Personally, I'm not shy about MySQL and I use it on my installations too. In my case, I needed to write some custom dialplan logic that would validate an employee who dialed in. We send a lot of guys out of town or out of the country for several weeks at a time to do equipment installations. We've been using Sprint calling cards to the tune of nearly $1.00/min. So I've got a toll-free number now that employees will be able to call, enter their employee number and their employee pin code, and get local dialtone. The employee numbers and pins codes are in a web-based time clock system that is backed by MSSQL. It didn't make sense to replicate the data from MSSQL to MySQL just for this functionality when unixODBC and FreeTDS made it so easy to connect from Asterisk to the MSSQL box. I also re-routed CDR over the the MSSQL box because I already have an OpenReports system working against that box. So it wasn't a situation where I shied away from MySQL because of unfamiliarity, it is simply a case where an ODBC connection makes more sense in my setup.
When I started to get into the meat of setting all this up, I found unixODBC was already part of the 2.4 distro but that Asterisk had not been built to support it. It seemed to me like I was ordering a milkshake and they didn't give me the straw.
Admittedly, I don't know if there are performance or stability issues with building Asterisk to include the ODBC support when it isn't going to be used... and ODBC connectivity might be a little beyond the average CE users... I don't know. Again, I looked at the distro, saw unixODBC was already included yet Asterisk wasn't built to include it. I thought that given the size of the CE community someone else had to be using ODBC. Maybe I'm just unique ;-)
I'm more than happy to contribute information on how to enable it and get connected to a datasource. I found that the information was out there but not all in one place and not always real clear. If Fonality is interested in enabling it in a future version, I would be thrilled to offer my setups as an example and to write detailed information on using it.
I absolutely agree that not
Tue, 04/15/2008 - 8:36am
I absolutely agree that not all decisions are based on total number of requests. We often take a number of variables into account and future use is sometimes one of them. I would like to see more people think they would use it before we see what it will take to implement and do all the compatibility testing.
While I personally have no
Tue, 04/15/2008 - 9:18am
Always fighting blot
Tue, 04/15/2008 - 9:29am
We are always fighting to not add more stuff to the iso. Most people want a stripped down phone system. If we add CDR ODBC we would have to add all the deps as well and it would add more stuff to the iso to test and keep updated.
One of the main reasons we use RPMs is it's really easy to download load our source RPMs and rebuild them with other features. Just download the source RPM for asterisk, remove cdr_odbc from asterisk-1.4.15-menuselect.makeopts, and rebuild. You will have cdr_odbc.
Really thought you will find it very easy to integrate Microsoft apps with mysql. I have all my CDRs auto update to Excel. All I did was load the mysql ODBC database connector on my windows box and import the data.
I understand bloat...
Tue, 04/15/2008 - 10:45am
Andrew,
I totally understand bloat avoidance and I totally agree with that. (although I think your assertion that people want a stripped-down system is off the mark... people use Trixbox because it is feature-rich, easy to setup, and reliable. I don't consider that stripped-down. A clean Linux distro and Asterisk built from source is stripped-down.)
However, as I mentioned in an earlier post, unixODBC is already installed by default. Asterisk only needs built against it. No other deps are required. (You need the /etc/odbc.ini and /etc/odbcinst.ini files, but those are simple text files) To enable it on my system, all I had to do was download Asterisk and Zap sources so I could rebuild it and enable the functionality. Nothing else was required. (Not completely true... I needed to install FreeTDS because I was talking to MSSQL... but not everyone needs that connector)
Also, the presence of cdr_odbc does not stop Asterisk from putting the CDR records in the local MySQL database. They are still there so ODBC support would really be a take it leave it type of thing. If someone wants to use it, fine... all they have to do is setup res_odbc.conf & func_odbc.conf to make it work. If they don't want it... that's fine too... do nothing. It doesn't seem to stop Asterisk from working.
The reason ODBC connection is important to me... other than the dialplan logic I needed as noted above... is that we are an MS house. And I've got a data backup and retention infrastructure that is already in-place and works with my existing SQL servers. Why would I introduce another database server into that environment? I'd have to get a backup license and agent for it, make sure people were trained to admin it, etc. As I have it now, I just include the Asterisk config files (much easier to backup than a DB) in my backup set and I'm good to go.
While I agree with you that setting up ODBC in Office is very easy and pulling the info into Excel is rather simple, it doesn't address my needs. ODBC support within Asterisk is the simplest, most reliable solution that I've got which is why I'm asking for out-of-the-box support. If it is in there as soon as I load the ISO, then I've got the option of using it with no headaches... because I know I can trust that if I load the ISO on a clean box... it is going to work. Trixbox has proven to me over the last several years (even pre-Fonality) to be very solid. I can trust a system to work. It isn't until I start messing with it that it starts to get unstable ;-)
Member Since:
2006-11-29