provided by Star2Billing S.L.

hi, still testing and now I got this error in admin login page when trying svn version:

Error : cannot load conf : load_conf_db

a2billing.conf is in /etc/ with its proper credentials and DB parameters.

any idea?
thanks
rafael

PS: I am testing the migration from 1.3.4 DB schema, is the UPDATE-a2billing-v1.3.4-to-v1.4.0.sql file updated?

Check your PHP and SQL log files to make sure this isn't simply a problem connecting to your SQL server.
The history shows there have been no changes that might fix the behaviour you're seeing since the release of v1.4.0beta.
I can't reproduce this problem myself, so I'm not sure what to suggest next, except perhaps re-install the SQL schema paying careful attention to any warnings or errors that may be emitted.

oops,, sorry for the bad info

I don't see how that ticket is related to this reported problem. The only changes made by that ticket were to the fresh v1.4.0 schema, rather than the v1.3.4->v1.4.0 upgrade rrisco is using.

In any case, rather than applying single changesets you should simply upgrade the whole A2B distribution to the latest version of trunk in our svn repo. That way you benefit from all the bug fixes made so far, rather than just the one you picked up on.

thanks stavros,

in fact my problem was solved upgrading to the latest version of trunk in the svn repo a few hours ago, as I am testing the DB migration from 1.3.4 I tried 'UPDATE-a2billing-v1.3.4-to-v1.4.0.sql' file and I believe that my database had not been updated properly the first time, now it works perfect in mysql.

The whole process last about 4 hours since I am testing this 'update' in a DB with more than 71000 users in cc_card, 300000 cdrs in cc_call , 384 callplans, 385 ratecards and almost 2millions of rates in cc_ratecard in my complex bussines model.

Right now I am running 'a2billing-prefix-table-v1.4.0.sql' script in which I should include my prefix list to properly update the 'destination' column in cc_call and cc_ratecard tables, the first problem I found in this phase is that I cannot insert non-number prefixes in 'prefix' column so I had to change this column type to VARCHAR to insert prefixes like 51S#7482 , the process is still running so I will report any other issue if appears.

regards
rafael

PS: I think cc_prefix should accept non-numeric prefixes too, please consider this possibility in the final release.

Yes, the upgrade can take quite a while. I've got a similarly complex setup, and it takes nearly 15 minutes for Postgres to finish.
v1.4 supports regular-expression prefixes, so you can already match strings if you want. You can't use 'N', 'X' or 'Z' though, as they will be re-written ('n', 'x', and 'z' should be fine).
I wouldn't add too many regex prefixes as they can result it a lot of extra load on your SQL server.