On 13/08/2012 08:28, Alex Peshkoff wrote:
>> This seems completely wrong solution. Our caller may not even have easy
>> access to setlocale (of the same CRT as ours).
>>
> Taking into an account that posix build is used not only on linux (have
> you ever seen linux with >1 CRT?) I can agree with th
On 08/13/12 14:37, Adriano dos Santos Fernandes wrote:
> On 13/08/2012 04:29, Alex Peshkoff wrote:
>> On 08/10/12 21:13, Dimitry Sibiryakov wrote:
>>> 10.08.2012 19:10, Adriano dos Santos Fernandes wrote:
Then bug will remains in embedded engine usage. It's not a good option
to let appl
On 13/08/2012 04:29, Alex Peshkoff wrote:
> On 08/10/12 21:13, Dimitry Sibiryakov wrote:
>> 10.08.2012 19:10, Adriano dos Santos Fernandes wrote:
>>> Then bug will remains in embedded engine usage. It's not a good option
>>> to let applications (ISQL or user ones) to deal with things that must
>>>
On 08/10/12 21:13, Dimitry Sibiryakov wrote:
> 10.08.2012 19:10, Adriano dos Santos Fernandes wrote:
>> Then bug will remains in embedded engine usage. It's not a good option
>> to let applications (ISQL or user ones) to deal with things that must
>> works automatically.
>Using locale informat
10.08.2012 19:10, Adriano dos Santos Fernandes wrote:
> Then bug will remains in embedded engine usage. It's not a good option
> to let applications (ISQL or user ones) to deal with things that must
> works automatically.
Using locale information or ignoring it is up to application developer.
On 10/08/2012 14:04, Dimitry Sibiryakov wrote:
> 10.08.2012 19:00, Adriano dos Santos Fernandes wrote:
>> Adding it on the server means also move it from isql to embedded library.
>No, the call in isql must remain as is. New call should be done from
> server executable,
> not engine library.
10.08.2012 19:00, Adriano dos Santos Fernandes wrote:
> Adding it on the server means also move it from isql to embedded library.
No, the call in isql must remain as is. New call should be done from server
executable,
not engine library.
--
WBR, SD.
-
On 10/08/2012 13:54, Dimitry Sibiryakov wrote:
> 10.08.2012 18:48, Adriano dos Santos Fernandes wrote:
>> I did not say I used ascii connection charset. The connection charset
>> does not matter in this phase.
>>
>> database_some_non_ascii_characters means a path with non-ascii characters.
>Ah,
10.08.2012 18:48, Adriano dos Santos Fernandes wrote:
> I did not say I used ascii connection charset. The connection charset
> does not matter in this phase.
>
> database_some_non_ascii_characters means a path with non-ascii characters.
Ah, sorry, I misunderstood you.
It looks like setlocal
On 10/08/2012 13:43, Dimitry Sibiryakov wrote:
> When you are connecting to database with non-ascii characters with
> ascii connection charset it is natural to receive error, no?..
I did not say I used ascii connection charset. The connection charset
does not matter in this phase.
database_some_
10.08.2012 18:39, Adriano dos Santos Fernandes wrote:
>> >The function to get the system charset is nl_langinfo(CODESET). Man page
>> >says:
>> >
>> >CODESET (LC_CTYPE)
>> > Return a string with the name of the character encoding used in
>> >the selected locale, such as "UTF-8", "ISO-8859-1",
On 10/08/2012 13:35, Adriano dos Santos Fernandes wrote:
> Hi!
>
> In 2.5 we presume that Linux system charset is UTF-8. In trunk iConv
> library is used for it.
>
> But it's causing different behavior of embedded / server mode.
>
> The function to get the system charset is nl_langinfo(CODESET). Ma
Hi!
In 2.5 we presume that Linux system charset is UTF-8. In trunk iConv
library is used for it.
But it's causing different behavior of embedded / server mode.
The function to get the system charset is nl_langinfo(CODESET). Man page
says:
CODESET (LC_CTYPE)
Return a string with the name o
13 matches
Mail list logo
