Re: postgresql-odbc vs. unixODBC

Hi,

> 
> does anybody know what the differences are between postgresql-odbc
> and unixODBC? because connection via postgresql-odbc work and
> via unixODBC fails!

you should check the driver versions. I think I remember seeing a post 
that said that the postgreSQL unixODBC is an outdated version of the 
postgreSQL ODBC driver that was included by the unixODBC team.

At any rate I'd always use the latest driver available directly from the 
ODBC team here.

Hajo

> 
> here some infos:
> 
> my /etc/odbcinst.ini:
> ---------------------
> [PostgreSQL]
> Description     = ODBC for PostgreSQL (postgresql-odbc)
> Driver          = /usr/lib/psqlodbc.so
> FileUsage       = 1
>  
> [PostgreSQL2]
> Description     = ODBC for PostgreSQL (unixODBC)
> Driver          = /usr/lib/libodbcpsql.so
> FileUsage       = 1

Re: select count(*) datatype ?

Am 30 Sep 2005 um 17:57 hat lothar.behrens <at> lollisoft.de geschrieben:

I have solved that problem. Open Watcom has a function atoll and lltoa for long
long conversion. I'll try this on Linux and Mac later, there may be similar functions.

Lothar

> Am 30 Sep 2005 um 9:54 hat Tom Lane geschrieben:
>
> > lothar.behrens <at> lollisoft.de writes:
> > > what type of column is an aggregated value of count ?
> >
> > bigint, at least in recent PG releases.
> >
> > 			regards, tom lane
> >
>
> Thanks,
>
> but now I am a little confused about how to convert those datatypes to a char[] type.
>
> I write long datatypes from char[] array into bound buffer:
>
> long l = 0;
> l = atol("long value");
> long* pl = (long*) buffer;
> void* b = pl+1;
> memcpy(b, &l, sizeof(l));
>
> I read long datatypes into char[] array from bound buffer:

Get error message details

In PgAdmin running code

create table t1 ( c1 serial primary key );
create table t2 ( c1 integer references t1);
insert into t1 values(1);
insert into t2 values (1);
delete from t1;

causes nice detailed error message

ERROR:  update or delete on "t1" violates foreign key constraint 
"t2_c1_fkey" on "t2"
DETAIL:  Key (c1)=(1) is still referenced from table "t2".

Runnign this code through ODBC I got only ERROR: line

How to retrieve the DETAIL: line using ODBC ?

Andrus. 

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

               http://archives.postgresql.org

Re: PATCH: Integrity constraint violation should set SQLSTATE to 23000

Thanks for pointing out a much better way to address the problem, Dave.

I've attached a patch that uses the SQLSTATE from the backend any time
the error condition after executing a query is
STMT_ERROR_TAKEN_FROM_BACKEND.  Besides solving the problem I reported,
this seems to make much more sense than setting the SQLSTATE arbitrarily
to HY000 "General Error" in this situation.  I look forward to your
feedback.

--
Chris Ingram
Software Developer, Intellisync Corporation
cingram <at> intellisync.com
www.intellisync.com

-----Original Message-----
From: Dave Page [mailto:dpage <at> vale-housing.co.uk] 
Sent: Friday, September 30, 2005 12:15 PM
To: Chris Ingram; pgsql-odbc <at> postgresql.org
Subject: RE: [ODBC] Integrity constraint violation should set SQLSTATE
to 23000

> -----Original Message-----
> From: pgsql-odbc-owner <at> postgresql.org 
> [mailto:pgsql-odbc-owner <at> postgresql.org] On Behalf Of Chris Ingram
> Sent: 30 September 2005 16:30
> To: pgsql-odbc <at> postgresql.org
> Subject: [ODBC] Integrity constraint violation should set 
> SQLSTATE to 23000
> 

Unbound text box, Text > 255 characters, MSAccess/PostgreSQL

Re: Unbound text box, Text > 255 characters, MSAccess/PostgreSQL

What version of Access?
Confirm that Access is interpreting the target field as MEMO, (either look at the linked table in design 
mode, or use Tools->Analyze->Documenter).
For the query, determine the "type" of the parameter - Query menu->Parameters. Be sure you are using type 
MEMO.

By the way, 3271 is a Jet error -- Invalid property value.

Good luck.

Zlatko Matić wrote:

> Hello.
> I have the following problem with MS Access/PostgreSQL combination:
> There is a form in Access that has an unbound text box, used for entering a commentary of a batch of records.
> There is a DAO Append Query that has a parameter that is passed from the text box using parameter of DAO
QueryDef object. 
> I adjusted B7 parameter (Text as LongVarchar) in connection string (ODBC driver) to 1, so that Access
links PostgreSQL Text fields as Memo fields in Access. The intention was to be able to enter unlimited
length commentary into the field.
> But, although I can enter unlimited text by using bound text box in some other forms, in this particular
form I can't use bound control, so I need to pass text from  UNBOUND control to the linked table by using DAO or
ADO code. It seems that DAO query can't accept Memo as parameter, but only text. If my text exceeds length of
255, I have an VBA error 3271. If text in unbound text box is shorter that 255 everything is OK.
> 
> So, is there any way to pass text of length >255 from unbound text box to Memo field of linked PostgreSQL
table, by using DAO or ADO ?
> 
> Thanks in advance,
> 
> Zlatko

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match

Re: PATCH: Integrity constraint violation should set SQLSTATE to 23000

> -----Original Message-----
> From: Chris Ingram [mailto:cingram <at> intellisync.com] 
> Sent: 03 October 2005 23:04
> To: Dave Page
> Cc: pgsql-odbc <at> postgresql.org
> Subject: RE: [ODBC] PATCH: Integrity constraint violation 
> should set SQLSTATE to 23000
> 
> Thanks for pointing out a much better way to address the 
> problem, Dave.
> 
> I've attached a patch that uses the SQLSTATE from the backend any time
> the error condition after executing a query is
> STMT_ERROR_TAKEN_FROM_BACKEND.  Besides solving the problem I 
> reported,
> this seems to make much more sense than setting the SQLSTATE 
> arbitrarily
> to HY000 "General Error" in this situation.  I look forward to your
> feedback.

Thanks Chris - patch applied.

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo <at> postgresql.org so that your
       message can get through to the mailing list cleanly

Just as an FYI We are up solid now on pgsql libpq version

Re: Just as an FYI We are up solid now on pgsql libpq version

Insecurity of ODBC debug logging files

I have a gripe here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154126
about the fact that ODBC is willing to store passwords into debug log
files that aren't secure.  Anyone want to do something about it?

Offhand it seems like simply omitting the password from the log wouldn't
be a bad idea.  But even then, a log file will frequently contain
sensitive data (eg, credit card numbers appearing in INSERT statements).
Seems to me that there should also be some care taken to make the log
file not world-readable.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match