God day community!

Task description.
Source DB is created with locale en_us.819 (default),
target DB is created with locale lv_lv.1257,
Win32 ESQL/C application must connect to both DB at the same time
and move some data from the source to the target.

Question.
So, is it possible? And if yes how to do the trick (environment, GLS files)?

Can you use ODBC instead? It's darn near trivial with ODBC, but I
can't say that it is even possible with ESQL/C.

"Leonid Vorontsov" <ifmx@inbox.lv> wrote in message news:<cjuaiu$m11$1@domitilla.aioe.org>...
> God day community!
>
> Task description.
> Source DB is created with locale en_us.819 (default),
> target DB is created with locale lv_lv.1257,
> Win32 ESQL/C application must connect to both DB at the same time
> and move some data from the source to the target.
>
> Question.
> So, is it possible? And if yes how to do the trick (environment, GLS files)?

Plausible Indirection wrote:

> Can you use ODBC instead? It's darn near trivial with ODBC, but I
> can't say that it is even possible with ESQL/C.

So, are you going to help, or just smirk behind the claim of triviality?

> "Leonid Vorontsov" <ifmx@inbox.lv> wrote:
>>Task description.
>>Source DB is created with locale en_us.819 (default),
>>target DB is created with locale lv_lv.1257,
>>Win32 ESQL/C application must connect to both DB at the same time
>>and move some data from the source to the target.
>>
>>Question.
>>So, is it possible? And if yes how to do the trick (environment, GLS files)?

I'm not sure whether it is possible, but...

Set the CLIENT_LOCALE to value A (en_us.819); connect to source DB.
Modify the CLIENT_LOCALE setting to value B (lv_lv.1257); connect to
target DB.

With luck, as you switch back and forth between connections, the
locale will also switch. If you're unlucky, you'll need to seek some
more Plausible Direction - possibly using ODBC after all.

My biggest concern is that Win32 uses SETNET32 and that may get in the
way of casually switching locales. It isn't all that easy in ESQL/C;
the setenv() function is not officially standardized.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"Jonathan Leffler" <jleffler@earthlink.net> wrote:
> So, are you going to help, or just smirk behind the claim of triviality?
Help, of course. Why do You doubt?

> I'm not sure whether it is possible, but...
I can quote e-mail from technical support:
ts> After conversation with the tools department it would
ts> seem that it is not possible to connect to two different locales from
the
ts> same application or program.
ts> I'm very sorry confusion and that there is no solution for what you want
to
ts> do.

> Set the CLIENT_LOCALE to value A (en_us.819); connect to source DB.
> Modify the CLIENT_LOCALE setting to value B (lv_lv.1257); connect to
> target DB.
Doesn't works. Once You have connected, You can modify environment
as You want without any effect.

> possibly using ODBC after all.
I've tried to use INTERSOLV driver (ivif7912.dll) without success.
This driver uses the same native API file (isqlt09a.dll).
So, result is the same.

> My biggest concern is that Win32 uses SETNET32 and that may get in the
> way of casually switching locales. It isn't all that easy in ESQL/C;
> the setenv() function is not officially standardized.
This is not a problem, Win32 API has fuctions for registry manipulations.

"Plausible Indirection" <cg22165@yahoo.com> wrote:
> Can you use ODBC instead?
I am not sure. Application is written on Centura really and uses native API.
It is possible to switch datasource from Informix to ODBC, but
nobody knows that all functionality will work correctly.

> It's darn near trivial with ODBC
Which ODBC driver do You recommend? I've tried Intersolv,
but this uses the same native dll. So, result is the same - can not
connect to 2 DB with different locales.

> How to connect to 2 DBs with different locales
> from one win32 esql/c application at the same time?

And so. If there is not any solution for the task mentioned in our
conference, I can think that this is impossible.

Leonid.

P.S. If I am wrong, please response.