1. 

   apao, Member

   Hello everyone,

   when I display my reports in HTML, accentuated characters are displayed as "?" in column headers (while the same characters outside column headers are ok).
   Is there a way to solve this?

   Best regards.
2. 

   myDBR Team, Key Master

   That should not happen as there is no difference how text is handled. Do you have an example of this? Do you use custom fonts?

   --
   myDBR Team
3. 

   apao, Member

   For instance, one of my column headers is "créé_par" and is displayed as "cr��_par".

   However, oustside column headers (i.e. in data itself), I have things like "Non spécifié", which are displayed correctly.

   EDIT : I have not defined anything special about fonts in myDBR.
4. 

   myDBR Team, Key Master

   What is the database and the database driver (if SQL Server) you are using?

   Can you create a short sample report (just select a string) and show the report code and the output when you run the report with '&export=sql' added to the URL.

   ---
   myDBR Team
5. 

   apao, Member

   I'm using an SQL Server 2012 Express Database.

   Which drivers do you mean? PHP drivers for SQL Server or ODBC drivers for SQL Server?

   The PHP drivers I use are "Microsoft Drivers 3.2 for PHP for SQL Server".

   There are 3 SQL Server ODBC drivers installed on my server :

   - ODBC Driver 11 for SQL Server (version 2011.110.2270.00)

   - SQL Server (version 6.01.7601.17514)

   - SQL Server Native Client 11.0 (version 2011.110.2100.60)

   I'm not 100% sure but I think it's the first one which is used.

   Here's the report code you asked for:

   IF object_id('sp_DBRtest','P') IS NOT NULL DROP PROCEDURE sp_DBRtest GO CREATE PROCEDURE sp_DBRtest AS BEGIN

   SELECT [créé_par] FROM mydbr.dbo.[001test]

   END GO

   The "&export=sql" parameter did not work (I had an error "Unknown export type: sql" when trying to access the URL).
   So I copy-paste what I have when I execute my stored procedure in the myDBR SQL Editor and activate the checkbox "Output as SQL" :

   select 'é ' as 'cr��_par'

   (my table has 1 char(10) column named "créé_par" and 1 line, containing only "é")
6. 

   myDBR Team, Key Master

   Hi,
   This turns out to be a bug in Microsoft PHP driver version you are using.

   To fix the issue, we have created a workaround for this. Run the updater to get the latest build (myDBR 4.4.0 (build 2695) as of this writing) and add following line to mydbr/user/defaults.php:

   $mydbr_defaults['db_connection']['fix_sqlsrv_field_metadata'] = true;

   This will convert the column titles into UTF-8.

   The '&export=sql' is a feature in Premium and OEM versions.

   --
   myDBR Team
7. 

   apao, Member

   Hello,
   this works perfectly.
   Many thanks for your responsiveness !
   Best regards.
8. 

   apao, Member

   Hi,
   I migrated this week and on my new machine, I use "Microsoft Drivers 5.6 for PHP for SQL Server" instead of "Microsoft Drivers 3.2 for PHP for SQL Server". I have issues with the headers of my reports, do I have to remove the line you had asked me to add when I was using 3.2?
   $mydbr_defaults['db_connection']['fix_sqlsrv_field_metadata'] = true;
9. 

   myDBR Team, Key Master

   Hi,
   yes, that setting is not needed anymore. The bug (wrong encoding in metadata) was in earlier versions of Microsoft PHO Drivers and was fixed by Microsoft in msphpsql's 4.0.8 release. Just remove the flag and the headers will be ok.

   --
   myDBR Team
10. 

    apao, Member

    Thanks for your answer.
    But is it normal that the setting now causes the issue?
    Without it, headers are ok with drivers 5.6.
    But when I keep the setting, I have trouble with accentuated headers, just as I had when I used drivers 3.2 without the setting.
    So is it normal?
11. 

    myDBR Team, Key Master

    Yes, that is perfectly normal.

    As said, you do not need that setting anymore now that the Microsoft has fixed the bug in the driver. The bug caused wrong encoding in metadata and the fix corrected it by converting the metadata to UTF-8. Now that the metadata is already UTF-8 to begin with, the second encoding from the fix would make the data incorrect.

    So, you only need (and should use) the fix with Microsoft Drivers 3.2 - 4.0.7.
    --
    myDBR Team
12. 

    apao, Member

    Ok, many thanks!

Reply

You must log in to post.