7

having a problem with an Access 2013 program that I need some outside insight on.

We have upgraded our terminal server to windows server 2012 r2 from windows server 2008 r2, along with Office 2010 ProPlus 32-bit to Office 2013 ProPlus 32-bit.

We have a few access programs that access our iSeries DB2 database, via odbc. All of them seem to be working well after the upgrade, bar one.

The specific program takes an input for work order and then produces a report to be printed. The output is a mixture of greek and english characters. When viewing in report view, text is fine, when you switch to print preview, text becomes garbled. See screenshots line starting with "batch number" below. Also this report contains a sub-report. Not sure if this is relevant.

Report View:

Report View

Print Preview:

Print Preview

Current language is set to Greek for non-unicode programs, and odbc settings mirror those of the previous server (language id and conversion of binary data).

I have also tried changing the font from tahoma to arial.

I have tried using different pdf printers and physical printers to see if it renders differently.

I have tried strConv([variable],0,[lcid]) and strConv([variable],64,[lcid]) with various possible LCIDs at the query level. Though I'm not sure I've exhausted this yet.

Looking at the data views in the underlying tables from the source DB, data is displayed correctly, also in the queries.

Not sure what is going wrong here, any ideas?

Dimitri Shukuroglou
  • 363
  • 1
  • 5
  • 13
  • 1st screen is report view, and everything is fine? 2nd screen is the problem? It's a bit hard to tell for someone who can't read Greek characters. :) -- Could it be a font problem? – Andre Sep 18 '17 at 10:47
  • Hi Andre, first screen is report view, second is print screen. Second is indeed the problem! compare line starting "batch number". Font used is tahoma if im not mistaken, which includes greek characters. – Dimitri Shukuroglou Sep 18 '17 at 11:06
  • Additional thoughts: In Report view, Access asks Windows to render characters x in font y. That works. In Print Preview, the printer driver is involved in addition. Can you try switching the report to a different printer (perhaps some "create PDF" driver)? – Andre Sep 18 '17 at 12:56
  • Hi Andre, I have switched printers using cutepdf, pdfcreator and two separate A4 laser printers (and associated drivers) – Dimitri Shukuroglou Sep 19 '17 at 05:32
  • A few more questions: 1) Is there any VBA in the report or the subreport? -- 2) The part where "Batch number" is the 4th record: Is this the subreport? Or the Detail section of the report? If subreport, what is the source object of it - a form or a report? The fields look sunken, which is a bit unusual for a report. -- 3) What happens if you open the subreport on its own? (both views?) – Andre Sep 20 '17 at 14:54
  • Can you provide some sample data, in text? (hard for us non-Greeks to write up a good test string to try to replicate) – Erik A Sep 20 '17 at 14:55
  • What is exact name of used Font? Is there 'Tahoma GREEK' or similar in the font list in properties of TextBox? Is there in Windows OS - Printers options(may be additional) - Font Substitutions ? – 4dmonster Sep 21 '17 at 08:16
  • Is there an option in the printer driver to not use printer fonts? – Mark3308 Sep 21 '17 at 15:19
  • 1
    Are you [grouping on a memo field](https://stackoverflow.com/questions/28776550/ms-access-query-returning-chinese-characters-possible-table-corruption?answertab=active#tab-top)? You tested the queries with grouping like report does and removed all groupings from the reports? Maybe you concat fields to more than 255 chars? – BitAccesser Sep 22 '17 at 21:08
  • have you installed unicode/greek fonts? – Krish Sep 26 '17 at 08:27

2 Answers2

1

Since your data seems to be fine in the tables and queries, I would suggest:

Copying all controls from design view of the report and paste them into a design view of a NEW report to see if it duplicates the problem.

If it does duplicate the problem then I would start designing the same report from scratch, starting with the problematic controls.

Frank
  • 31
  • 8
0

Couldnt fix this in MS access. Instead I dealt with it using SSIS.

Loaded Data from source db as ibm codepage 875, the converted to windows codepage 1252 then to unicode. Works fine now.

Dimitri Shukuroglou
  • 363
  • 1
  • 5
  • 13