provided by Star2Billing S.L.

Hi there,

This has been a great project indeed, congratulations!

I wonder if there is a possibility to have the DESCRIPTION of the called destination as part one of the available fields when the CDR is exported to CSV.

On screen you can see "Colombia Comcel Mobile" "Canada Mobile" etc, etc. but when the report is exported, all I can see is the numeric prefix of the dialed destinations, something that is not very useful for customers.

Is there a possibility that you could modify the CDR export procedure to export the DESCRIPTION/NAME of the dialed destinations instead of the numeric prefixes?

Thank you in advance,

Paul

Hi

I think it is important that the dialcode should be left in so that you can do a sanity check to ensure that the routing is happening as it should.

e.g. you have a call to 44906 - a UK sexline, charged at £5 per minute, and you discover in your cdr that it is somehow being charged at the 44 rate which may be £0.02 per minute.

With a copy of access, and an export of the prefix table and the CDR, you should be able to do a nice report to output to your customers.

I've also seen used ireports from Jaspersoft to connect directly to the A2Billing DB to create nice reports, and with Access 2007, and the latest ODBC MySQL drivers, you can have MS Access connect directly to the DB, and produce reports, but remember this can write as well as read, so be careful.

You could put in a feature request to add this field, and it can be considered with all the other improvements we have in the todo list, or if this is important and urgent to you, then you could consider sponsoring the development of this. It probably would not be expensive, and would move this feature to the the top of the todo list.

Joe

As Joe stated microsoft access is really usefull for reports and working with data in your MYSQL.

To all trying t0 use access to connect to your mysql.. Some tips

When using access I normally use Connector-ODBC 3.51.27 and found it works better than latest but maybe i never got Connector-ODBC 5.1.6 configured right and thats the reason i have trouble with it.

Data types i had trouble with IN microsoft access. I change almost everything in the MYSQL from "any"INT types to just INT all except a couple places where BIGINT is used.
BIGINT <== nice but takes up more space than "INT" and causes hell with Access when using a Connector-ODBC.
float Grrr <=== i hate this data type.. Doesnt work well in access and I always change it to "double"
char <===works in access quite well but takes up too much space in the MYSQL DB So I change it to varchar
Timestamp <== mysql fields cant be edited in Access unless last column in table is an extra timestamp.
primary "ID" fields also helps being in tables you want to edit with access. without them strange things can happen.

mysql VEIWS in some versions of MYSQL doesnt work at all in access. (maybe all versions I havent tried the last one)

Hi

You will find the latest version of MS Access is, as far as I can make out, faultless when connecting to MySQL, where as before in earlier versions - aaaaagh.

Joe

Hi joe
That is really good news. I have been using Access for 14 years and love the way its easy to use can link to most data types. I have access 2007 now.. Is that the version you are refering to?
are you using Connector-ODBC 5.1.6?
I am using Connector-ODBC 3.51.27. Because it has extra settings which i can force it to work.
I never got Connector-ODBC 5.1.6 working right probably because I never adjusted any settings which i believe are located in some ini file and probably why I am having some issues with it.

I am sure Connector-ODBC 5.1.6 is much better than Connector-ODBC 3.51.27.
Do you have a ini or configuration file you configured for Connector-ODBC 5.1.6 which you can post or upload here?

I almost switched from mysql to psql at one time because of the issues with mysql Connector-ODBC.
The Connector-ODBC for psql works perfectly. Only reason I didnt is because there are too many tools for mysql like PHP generators that doesnt work with psql .

Best regards
Sam

Hi Joe
Ok correction
I wasnt using the latest Connector-ODBC 5.1.6?
I was using 5.1 but not version 5.1.6
many of the problems I had to work around were bugs and which have since been fixed in Connector-ODBC 5.1.6.
Plus Connector-ODBC 5.1.6 now has all the settings like 3.51 has.

quick update: The new Connector-ODBC 5.1.6 works almost flawless. But there are somethings to look for if anyone has trouble adding or editing records in mysql using access

1. Some cases when certain data types are used when there are no primary key field in the table you wont be able to add-insert new records. (I didnt finish testing to find what data type is cuasing this issue)
2. TimeStamps MYSQL fields can never be edited in access unless you make another TimeStamps field after the first one. The last timestamp field in the table can never be edited.
3. If "bit" data type is ever used there must be a timestamp field in the table or you will not be able to EDIT records even though you can add-insert new records

After downloading Connector-ODBC 5.1.6 and installing I open the help file and found some additional info that I posted below...

With all applications you should ensure that you are using the latest Connector/ODBC drivers, ODBC Manager and any supporting libraries and interfaces used by your application. For example, on Windows, using the latest version of Microsoft Data Access Components (MDAC) will improve the compatibility with ODBC in general, and with the Connector/ODBC driver.


6.2.1. Using Connector/ODBC with Microsoft Applications
The majority of Microsoft applications have been tested with Connector/ODBC, including Microsoft Office, Microsoft Access and the various programming languages supported within ASP and Microsoft Visual Studio.


6.2.1.1. Microsoft Access
To improve the integration between Microsoft Access and MySQL through Connector/ODBC:

For all versions of Access, you should enable the Connector/ODBC Return matching rows option. For Access 2.0, you should additionally enable the Simulate ODBC 1.0 option.

You should have a TIMESTAMP column in all tables that you want to be able to update. For maximum portability, do not use a length specification in the column declaration (which is unsupported within MySQL in versions earlier than 4.1).

You should have a primary key in each MySQL table you want to use with Access. If not, new or updated rows may show up as #DELETED#.

Use only DOUBLE float fields. Access fails when comparing with single-precision floats. The symptom usually is that new or updated rows may show up as #DELETED# or that you cannot find or update rows.

If you are using Connector/ODBC to link to a table that has a BIGINT column, the results are displayed as #DELETED#. The work around solution is:

Have one more dummy column with TIMESTAMP as the data type.

Select the Change BIGINT columns to INT option in the connection dialog in ODBC DSN Administrator.

Delete the table link from Access and re-create it.

Old records may still display as #DELETED#, but newly added/updated records are displayed properly.

If you still get the error Another user has changed your data after adding a TIMESTAMP column, the following trick may help you:

Do not use a table data sheet view. Instead, create a form with the fields you want, and use that form data sheet view. You should set the DefaultValue property for the TIMESTAMP column to NOW(). It may be a good idea to hide the TIMESTAMP column from view so your users are not confused.

In some cases, Access may generate SQL statements that MySQL cannot understand. You can fix this by selecting "Query|SQLSpecific|Pass-Through" from the Access menu.

On Windows NT, Access reports BLOB columns as OLE OBJECTS. If you want to have MEMO columns instead, you should change BLOB columns to TEXT with ALTER TABLE.

Access cannot always handle the MySQL DATE column properly. If you have a problem with these, change the columns to DATETIME.

If you have in Access a column defined as BYTE, Access tries to export this as TINYINT instead of TINYINT UNSIGNED. This gives you problems if you have values larger than 127 in the column.

If you have very large (long) tables in Access, it might take a very long time to open them. Or you might run low on virtual memory and eventually get an ODBC Query Failed error and the table cannot open. To deal with this, select the following options:

Return Matching Rows (2)

Allow BIG Results (8).

These add up to a value of 10 (OPTION=10).