B
BigJohn
We are moving from 2 tier (ASP.Net to SQL 2005) to 3 tier (ASP.Net to Web
Service using SOAP to SQL 2005) with MS Access 2003 as the reporting engine.
It turns out SOAP changes the vbCrLf so the Access reporting engine will not
recognize it properly and display multiple lines. The result is a bullet
style dot used for an unrecognized character.
in the debugger, when we display the field value in the Immediate window,
the line returns are displayed fine but the final report rendering is not
accurate. The character value is chr(10) which is usually what I use to
insert a carriage return. I have even tried replacing chr(10) with chr(10)
in the reports input query thinking it is partially accurate and the replace
will override it but to no avail.
Data is properly displayed with the 2-tier (non-SOAP) processed information,
but not with the SOAP processed data.
In Studio.Net, if I use Crystal against the data it is properly displayed.
I have quite a few reports in MS Access and do not want to migrate to Crystal
if I don't have to.
The public blogs suggest I change my SOAP connections to Base64, but that
has consequences in other areas which are worse.
What can I do with MS Access to correct this issue?
Service using SOAP to SQL 2005) with MS Access 2003 as the reporting engine.
It turns out SOAP changes the vbCrLf so the Access reporting engine will not
recognize it properly and display multiple lines. The result is a bullet
style dot used for an unrecognized character.
in the debugger, when we display the field value in the Immediate window,
the line returns are displayed fine but the final report rendering is not
accurate. The character value is chr(10) which is usually what I use to
insert a carriage return. I have even tried replacing chr(10) with chr(10)
in the reports input query thinking it is partially accurate and the replace
will override it but to no avail.
Data is properly displayed with the 2-tier (non-SOAP) processed information,
but not with the SOAP processed data.
In Studio.Net, if I use Crystal against the data it is properly displayed.
I have quite a few reports in MS Access and do not want to migrate to Crystal
if I don't have to.
The public blogs suggest I change my SOAP connections to Base64, but that
has consequences in other areas which are worse.
What can I do with MS Access to correct this issue?