gmane.comp.db.postgresql.odbc

Re: Update For Outdated Win98

BGoebel — 2012-05-16T18:06:41

...

not so far failed

...
Interesting. Is there a list of what APIs it adds or adjusts?

i did not found what is implemented, but some challenging applications are
"supported" :Firefox 8, Open Office ,.... 
   


Mark Morgan Lloyd-2 wrote


--
View this message in context: http://postgresql.1045698.n5.nabble.com/Update-For-Outdated-Win98-tp5693458p5708956.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

Re: Update For Outdated Win98

Mark Morgan Lloyd — 2012-05-09T11:21:09

To remove ambiguity: do you mean you've had it running and it's not so 
far failed, or you've had it running and it's recently failed? :-)


Interesting. Is there a list of what APIs it adds or adjusts?


All of us have much to be grateful to him for.

Update For Outdated Win98

BGoebel — 2012-05-08T11:38:07

I admit, nowadays an exotic szenario:

Running a PostgreSQL client on an Windows 98 machine.

The 9.1 pSQLOdbc Driver uses some Kernel32.DLL functions which were
introduced with  WindowsXP.
such as TryEnterCriticalSection().

I updated Windows 98 with KernelEx 4.5.2 http://kernelex.sourceforge.net/
and the brandnew 2011 pSQLOdbc driver runs with our application without a
problem until now. We are using UTF8 Charsets with the psqlodbca.dll, UTF 16
with psqlodbcw.dll might be an issue.

KernelEx is a compatibility layer for running Win2000+ apps.

I have tested it with Win98 running in a VM, but i am sure pSQLODBC will
work with a real machine too.

Special thanks go to Hiroshi Inoue for his hint.
 




--
View this message in context: http://postgresql.1045698.n5.nabble.com/Update-For-Outdated-Win98-tp5693458.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

Re: using pgsql-odbc using client certificate auth

Stephen Frost — 2012-05-04T16:53:53

Hiroshi, all,

* Stephen Frost (sfrost< at >snowman.net) wrote:

Ok, I've been able to make it use the Windows certificate store for the
SSL Key (at least..).  Unfortunately, it won't use the certificate store
for the actual certificate or the root chain (yet...).  When it comes to
the ODBC distribution, here's what I'd really like to see:

Please add the 'capi.dll' file to the ODBC distribution, it's part of
OpenSSL and should be installed next to libeay32.dll.  Unfortunately,
that's not all that's needed to make it work- you also need an
openssl.cfg file to be installed, ideally with the ODBC driver too,
with these contents:

---------------------------------------------------
openssl_conf = openssl_init

[openssl_init]
oid_section = new_oids
engines = engine_section

[engine_section]
capi = capi_config

[capi_config]
engine_id = capi
dynamic_path = "c:\\program\ files\ \(x86\)\\psqlodbc\\0901\\bin\\capi.dll"
init=1
---------------------------------------------------

We also need to tell OpenSSL where to find

Re: How can I keep an OdbcDataAdapter from using fully qualified tble names?

George Weaver — 2012-04-25T15:12:03



I think you'll find that it is not ADO.Net's OdbcDataAdapter that expands 
the table name, but
the CommandBuilder - I use ADO Net's OdbcDataAdapter extensively without 
problem,
but I write my own OdbcCommands.

George

Re: How can I keep an OdbcDataAdapter from using fully qualified tble names?

Nils Gösche — 2012-04-25T15:02:01


[...]


I used to have the same problem and gave up on it a long time ago. I
just tried to reproduce it again and...failed!

I suspect it's because we have switched to VS 2010 in the meantime. Could
you perhaps check if your problem goes away, too, if you compile with VS
2010?

Thanks for bringing it up, anyway :-) :-) :-)

Regards,

Re: How can I keep an OdbcDataAdapter from using fully qualified tble names?

Rob Richardson — 2012-04-25T14:52:40

The issue is that ADO.Net's OdbcDataAdapter object automatically expands the 
table name "MyTable" into "MyDatabase.public.MyTable", and PostgreSQL cannot 
handle that.

In PgAdmin, "insert into cycle (cycle) values ('Another cycle')" succeeds, but 
"insert into Anneal.public.cycle (cycle) values ('Another one')" fails with the 
cross-database references not implemented error.  The OdbcDataAdapter object 
automatically converts a query of the first form into a query of the second 
form, and I want to know how to stop it from doing that.

RobR

Re: How can I keep an OdbcDataAdapter from using fully qualified tble names?

Barry Bell — 2012-04-25T14:35:11

Your SQL"select * from DBNAME.TABLENAME"  
Instead of just " select * from TABLENAME"  ?

Does the user use a different DB Login then you do?
Try logging as the user into pgadmin and run the SQL.

If you have the same issues, the issue is with the user access rights (or under which right a view/table was created).


Thanks
Barry Bell, IT Department 
Office: 954-429-3771 x267 Fax: 954-281-1464 email Barry_Bell< at >harte-hanks.com


-----Original Message-----
From: pgsql-odbc-owner< at >postgresql.org [mailto:pgsql-odbc-owner< at >postgresql.org] On Behalf Of Rob Richardson
Sent: Wednesday, April 25, 2012 10:25 AM
To: pgsql-odbc< at >postgresql.org
Subject: Re: [ODBC] How can I keep an OdbcDataAdapter from using fully qualified tble names?

I want to stick with DSNs because we change databases frequently, mainly on our own systems.  Develop first using a test database, then do final testing on a copy of the customer's production database, then, if problems crop up, get an up-to-date copy of the customer's dat

Re: How can I keep an OdbcDataAdapter from using fully qualified tble names?

Rob Richardson — 2012-04-25T14:25:10

I want to stick with DSNs because we change databases frequently, mainly on our 
own systems.  Develop first using a test database, then do final testing on a 
copy of the customer's production database, then, if problems crop up, get an 
up-to-date copy of the customer's database and debug using that.  That's what 
DSNs are for.  They work.  (At least until the .Net world apparently decided it 
knows better.)

I think you're thinking of a different issue.  I'm not talking about a fully 
qualified name of a server, with "mycompany.com" appended to it.  I'm talking 
about a fully qualified table name, with the database name and schema prepended 
to it.

RobR

Re: How can I keep an OdbcDataAdapter from using fully qualified tble names?

Barry Bell — 2012-04-25T14:11:58

It maybe a dns issue, The below connection works because server "my-server"
Resolves in my land from "my-server" to "my-server.mycompany.com".

Driver={PostgreSQL ANSI};Server=my-server;Port=5432;Database=dbname;Uid=user;Pwd=password;BI=2;TextAsLongVarchar=1;UnknownSizes=2;UnknownsAsLongVarchar=1;UseServerSidePrepare=1;

Does this help?

Why not go DSN-less? (Put the connection string into an INI disturbed with the program?) 
Otherwise, you will goto every computer and Update the DSN whenever the server or db name is changed


Thanks
Barry Bell, IT Department 
Office: 954-429-3771 x267 Fax: 954-281-1464 email Barry_Bell< at >harte-hanks.com


-----Original Message-----
From: pgsql-odbc-owner< at >postgresql.org [mailto:pgsql-odbc-owner< at >postgresql.org] On Behalf Of Rob Richardson
Sent: Wednesday, April 25, 2012 10:06 AM
To: pgsql-odbc< at >postgresql.org
Subject: [ODBC] How can I keep an OdbcDataAdapter from using fully qualified tble names?

Hello!

How can I keep an OdbcDataAdapter from insisting o

How can I keep an OdbcDataAdapter from using fully qualified tble names?

Rob Richardson — 2012-04-25T14:05:50

Hello!

How can I keep an OdbcDataAdapter from insisting on the fully qualified table 
name?


In VS 2008, I am trying to use the System.Data.Odbc namespace to work with a 
PostGres database.  I don't want to use npgsql because I want to work with DSNs 
so that I get the flexibility of changing databases without changing my 
program.  


When I use an OdbcCommandBuilder object to create the insert, update and delete 
commands for me, the table names are fully qualified.  For example, an insert 
command might begin with "insert into MyDatabase.public.MyTable...".  When I try 
to use that, I get an exception thrown that complains that cross-database 
references are not implemented (even though the connection I am using is to the 
MyDatabase database).  


So, I wrote a little function that converts a string containing 
"MyDatabase.public.MyTable" into "MyTable", and use that to replace the fully 
qualified name in the command text with the bare table name.  But when it comes 
to time to call the adapter's Upda

Advanced Options - OID

Jan-Peter Seifert — 2012-04-23T11:21:59

Hello,

if 'Advanced Options' -> 'OID Options' -> 'Show Column' is activated ODBC
function SQLColumns() retrieves one more row than expected if you use the function's filter ColumnName.
If you check for the existence of a column that does not exist you get one
instead of no result row.
If you check for the existence of a column that does exist you get two instead of one row and the correct row is the second and not the first one.

Could you check this, please?

Thank you very much,

Peter Seifert

Re: Passing numeric Bind variables to ODBC driver convers to "Double precision"

Hiroshi Inoue — 2012-04-13T22:27:42

Could you send me the Mylog output?
You can take the log by adding Debug=1; in your connection string.

regards,
Hiroshi Inoue

Re: Passing numeric Bind variables to ODBC driver convers to "Double precision"

Barry Bell — 2012-04-13T18:00:12

Note: The UseServerSidePrepare=1; only works with the PostgresSQL 9.01 driver (It will not work with the 9.00 driver)

Setting TextAsLongVarchar=0 has no effect on the blanks("") comes back as longvarchar.

UnknownsAsLongVarchar=0 or UnknownsAsLongVarchar=1 has no effect on this either.


Thanks
Barry Bell, IT Department 
Office: 954-429-3771 x267 Fax: 954-281-1464 email Barry_Bell< at >harte-hanks.com


-----Original Message-----
From: Hiroshi Inoue [mailto:inoue< at >tpf.co.jp] 
Sent: Friday, April 13, 2012 9:27 AM
To: Barry Bell
Cc: pgsql-odbc< at >postgresql.org
Subject: Re: [ODBC] Passing numeric Bind variables to ODBC driver convers to "Double precision"

(2012/04/13 2:12), Barry Bell wrote:

Please try to turn off the Text as LongVarChar option.

regards,
Hiroshi Inoue

Re: UPDATE table via ODBC fails.

Richard Broersma — 2012-04-13T15:22:03



You'll find that reading the logs produced by the PostgreSQL server to
be much more informative about the miss behavior your experiencing.

Can you post the logs generated by PostgreSQL, when you attempt this
UPDATE statement?

Re: Passing numeric Bind variables to ODBC driver convers to "Double precision"

Hiroshi Inoue — 2012-04-13T13:27:05

Please try to turn off the Text as LongVarChar option.

regards,
Hiroshi Inoue

Re: Passing numeric Bind variables to ODBC driver convers to "Double precision"

Barry Bell — 2012-04-12T17:12:19

Thanks, "UseServerSidePrepare=1;  does appear to fix this. (working for both numeric and integer)

Next issue,
When calling a function in postgres, the postgres is returning a blank string ('').
This is showing as a blank longvarchar(memo,clob) instead of a varchar.

Any ideas?
 
Thanks
Barry Bell, IT Department 
Office: 954-429-3771 x267 Fax: 954-281-1464 email Barry_Bell< at >harte-hanks.com


-----Original Message-----
From: Hiroshi Inoue [mailto:inoue< at >tpf.co.jp] 
Sent: Thursday, April 12, 2012 9:24 AM
To: Barry Bell
Cc: pgsql-odbc< at >postgresql.org
Subject: Re: [ODBC] Passing numeric Bind variables to ODBC driver convers to "Double precision"

Hi Barry,

(2012/04/09 23:35), Barry Bell wrote:

Are you turning on the Server side prepare option?

regards,
Hiroshi Inoue

Re: Passing numeric Bind variables to ODBC driver convers to "Double precision"

Hiroshi Inoue — 2012-04-12T13:24:09

Hi Barry,

(2012/04/09 23:35), Barry Bell wrote:

Are you turning on the Server side prepare option?

regards,
Hiroshi Inoue

Re: UPDATE table via ODBC fails.

Ken Benson — 2012-04-12T00:25:02

UPDATE:

This must have something to do with the multiple table involvement.

I modified my 'insert' command to include the updated field on the 
initial insert.

    INSERT INTO tmp_rxpurge (rxnum,dt_wrt,dt_lastfill,b_purge)
    SELECT "RXNUM","DATE",rf.dt_lastfill,'f'
    FROM rx
    LEFT JOIN  (SELECT "RXNUM" AS rxnum, Max("DATE")  as dt_lastfill
    FROM transactions GROUP BY "RXNUM")
                 as rf on rf.rxnum=rx."RXNUM"


Then - created three additional update steps ... they all worked via the 
ODBC connector...

 1. UPDATE tmp_rxpurge SET dt_lastact=dt_wrt
 2. UPDATE tmp_rxpurge SET dt_lastact=dt_lastfill where dt_lastfill IS
    NOT NULL and dt_lastfill > dt_lastact
 3. UPDATE tmp_rxpurge SET b_purge='t' where dt_lastact < '2010-01-01'


I'm still puzzled why the first method didn't work.

Ken

On 4/11/2012 3:01 PM, Ken Benson wrote:

UPDATE table via ODBC fails.

Ken Benson — 2012-04-11T22:01:36

I have a fairly straightforward routine which uses an ODBC connection to 
do 4 steps:

  * DROP TABLE IF EXISTS tmp_rxpurge
  * CREATE TABLE tmp_rxpurge (rxnum VARCHAR(300),dt_wrt DATE,dt_lastfill
    DATE,dt_lastact DATE, b_purge BOOLEAN)
  * INSERT INTO tmp_rxpurge (rxnum,dt_wrt,b_purge) SELECT
    "RXNUM","DATE",'f' FROM rx
  * UPDATE tmp_rxpurge as t SET dt_lastfill = rf.dt_lastfill FROM
    (SELECT "RXNUM" AS rxnum, Max("DATE") as dt_lastfill FROM
    transactions GROUP BY "RXNUM") as rf WHERE rf.rxnum=t.rxnum


The first three commands are executed perfectly as expected.
The update fails to do anything.
There is no error generated.
I have enabled 'logging' in the ODBC connector - and I don't see 
anything out of the ordinary in the short-log. (The long-log - I have no 
idea what all that stuff means.)

If I copy that last command into a psql window - it executes - and works 
fine.

But - it will not work via the ODBC connector.

What's going on?

Ken

Re: Problem with Use Declare/Fetch

Alexandre - Aldeia Digital — 2012-04-11T19:21:28

Hi Hiroshi,

Em 11-04-2012 10:38, Hiroshi Inoue escreveu:


Very strange. I will try again and send you the results.



Ok.


Best regards,

Alexandre