[fdo-users] Re: SL-King SpatiaLite FDO Provider - encoding issues
with column names
haris at sl-king.com
Thu Mar 24 09:56:13 EDT 2011
I looked into fdo multibyte_to_wide macro and it seems it uses
MultiByteToWideChar which has parameter to convert from UTF-8
multibyte to wide char ( using parameter CP_UTF8 but in fdo it uses
Anyhow, I will implement your patch. I assume you tested it as well.
On Wed, Mar 23, 2011 at 7:30 PM, Ryan Proulx <ryan.proulx at safe.com> wrote:
> Perhaps this is not quite the right forum, but despite being successful
> using the new SL-King SpatiaLite FDO Provider (version 0.1.2 as made
> available here) to read from SpatiaLite databases we have encountered a few
> issues with encoded column names when round tripping to and from SpatiaLite.
> Using the provided sandbox source code, it appears that though the provider
> writes the encoded column name correctly, mapping the UTF-16 name in FDO to
> the UTF-8 string using the FDOStringP class, when reading the opposite
> mapping is not occurring. Instead in
> c_FdoSlite_API2::DescribeTableProperties there is an attempt to use the
> 'multibyte_to_wide' macros. These macros are ineffective in this context as
> they only widen the data type (from char* to wchar_t*) but do not change the
> encoding (from UTF-8 to UTF-16) as expected by the FDO. An alternative might
> have been to use the UTF-16 API calls instead but in the name of parallelism
> the FDOStringP seemed more appropriate.
> I have provided a very simple patch file to correct the issue and if it
> meets with your approval would like to see it in the next version of the
> provider (if it has not been fixed already).
> Do you have a rough estimate when we will see the next version of this
> provider or better yet become a complete citizen of FDO?
More information about the fdo-users