Sorry for top posting but this thread is getting really long now and
getting difficult to follow.
Good point Alexander and noted but I still feel the issue is way beyond
whether UTF-8 encoded data is in the script or not as in my examples (as
in the ones you provided when you did the original unic
On 30.09.2009 15:39, Martin Evans wrote:
Does your setup pass the DBD::ODBC tests?
No, it does not:
t/40UnicodeRoundTrip.t
At least this test should pass without warnings and errors. If it
doesn't, the following Unicode tests do not make sense at all.
You are entering a world of
Martin Evans wrote:
> Stephan Austermühle wrote:
>> Hello Martin,
>> Martin Evans schrieb:
>>
>>> What do you mean by that? Select stops working it you stipulate your
>>> perl script is utf-8?
>> Yes: When adding "use encoding 'utf8'" the result reads like this:
>>
>> 1 G?nz v?le ?ml?ute und
Stephan Austermühle wrote:
> Hello Martin,
> Martin Evans schrieb:
>
>> What do you mean by that? Select stops working it you stipulate your
>> perl script is utf-8?
>
> Yes: When adding "use encoding 'utf8'" the result reads like this:
>
> 1 G?nz v?le ?ml?ute und ?eugs
>
>> You need to u
Guys,
maybe this is the problem:
DBD::ODBC assumes a default column bind type of SQL_WVARCHAR with Unicode builds if SQLDescribeParam is unavailable. Accepting
this default setting results in
DBD::ODBC::st execute failed: [unixODBC][FreeTDS][SQL Server]Invalid
data type (SQL-HY004) a
On 2009-09-30 08:45:47 +0200, Stephan Austermühle wrote:
> By the way, UTF-16 != UCS-2LE?
Yes. UCS-2 is restricted to Unicode codepoints <= 0x. UTF-16 is an
extension of UCS-2 which encodes the codepoints bertween 0x1_ and
0x10_ (IIRC) as a series of two 16-bit values. Both can be litt
