I just replied to this on pgsql-odbc mailing list. Since we're talking
about client performance, please keep the discussion there.
On 09/05/2014 08:54 AM, Vladimir Romanov wrote:
Hello all!
I do some test with ODBC driver for PosgreSql, TimesTen & MySQL. I compare
performance on very simple req
Hello all!
I do some test with ODBC driver for PosgreSql, TimesTen & MySQL. I compare
performance on very simple request. Database always located on same PC as
test application. Test PC - Lenovo T500, Cnetos 6.5 64, 8 Gb RAM, SSD.
I found what PostgreSql ODBC driver is slowest in comparison.
IMHO p
(2013/07/19 22:03), Andres Freund wrote:
On 2013-07-19 08:57:01 +0900, Inoue, Hiroshi wrote:
I had the idea they were used for a client-side implementation of WHERE
CURRENT OF. Perhaps that's dead code and could be removed entirely?
It's been reported that ODBC still uses them.
Though Postg
On 2013-07-19 08:57:01 +0900, Inoue, Hiroshi wrote:
> >>I had the idea they were used for a client-side implementation of WHERE
> >>CURRENT OF. Perhaps that's dead code and could be removed entirely?
> >
> >It's been reported that ODBC still uses them.
>
> Though PostgreSQL's TID is similar to Or
(2013/07/18 23:54), Robert Haas wrote:
On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote:
Robert Haas writes:
1. snapshot-error-v1.patch introduces a new special snapshot, called
SnapshotError. In the cases where we set SnapshotNow as a sort of
default snapshot, this patch changes the code to
On Thu, Jul 18, 2013 at 12:25 PM, Alvaro Herrera
wrote:
> Ah, yeah, that does show up. I had grepped for 'currtid_'. Sorry.
> They're all in positioned_load() in results.c.
Well, in that case, we'll have to keep it around. I still wish we
could get a clear answer to the question of how it's be
Andres Freund escribió:
> On 2013-07-18 12:01:39 -0400, Robert Haas wrote:
> > On Thu, Jul 18, 2013 at 11:54 AM, Alvaro Herrera
> > wrote:
> > > They don't show up in a quick grep of psqlodbc's source code, FWIW.
> >
> > Hmm. Maybe we should just remove them and see if anyone complains.
> > We c
On 2013-07-18 12:01:39 -0400, Robert Haas wrote:
> On Thu, Jul 18, 2013 at 11:54 AM, Alvaro Herrera
> wrote:
> > They don't show up in a quick grep of psqlodbc's source code, FWIW.
>
> Hmm. Maybe we should just remove them and see if anyone complains.
> We could always put them back (or make the
On Thu, Jul 18, 2013 at 11:54 AM, Alvaro Herrera
wrote:
> They don't show up in a quick grep of psqlodbc's source code, FWIW.
Hmm. Maybe we should just remove them and see if anyone complains.
We could always put them back (or make them available via contrib) if
it's functionality someone actual
Robert Haas escribió:
> On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> 1. snapshot-error-v1.patch introduces a new special snapshot, called
> >> SnapshotError. In the cases where we set SnapshotNow as a sort of
> >> default snapshot, this patch changes the code to
On Thu, Jul 18, 2013 at 10:34 AM, Tom Lane wrote:
> Robert Haas writes:
>> 1. snapshot-error-v1.patch introduces a new special snapshot, called
>> SnapshotError. In the cases where we set SnapshotNow as a sort of
>> default snapshot, this patch changes the code to use SnapshotError
>> instead.
Robert Haas writes:
> 1. snapshot-error-v1.patch introduces a new special snapshot, called
> SnapshotError. In the cases where we set SnapshotNow as a sort of
> default snapshot, this patch changes the code to use SnapshotError
> instead. This affects scan->xs_snapshot in genam.c and
> estate->e
> Thansk you very much for the inforamtion. We tried Postgres ODBC Driver
> (ANSI. Now we can view the datatype varchar/text.
>
> But since there is a limitation of Ascii character set, we are unable to
> view Latvian Specific characters.
>
> If you have any idea about this, please let me know
> Thansk you very much for the inforamtion. We tried Postgres ODBC Driver
> (ANSI. Now we can view the datatype varchar/text.
>
> But since there is a limitation of Ascii character set, we are unable to
> view Latvian Specific characters.
>
> If you have any idea about this, please let me know
Hi
Thansk you very much for the inforamtion.
We tried Postgres ODBC Driver (ANSI. Now we can view the datatype
varchar/text.
But since there is a limitation
of Ascii character set, we are unable to view Latvian Specific characters.
If you have any idea about this,
please let me know.
Thanks &
Edward,
> To help with my work, I've created a basic plugin that allows Postgres
> to retreive data from tables on other databases via ODBC. So far I've
> only tested it against MS SQL Server 2000. It's rather crude at the
> moment, as the only operation supported is a SELECT * query, and it
> cur
Hello all,
To help with my work, I've created a basic plugin that allows Postgres
to retreive data from tables on other databases via ODBC. So far I've
only tested it against MS SQL Server 2000. It's rather crude at the
moment, as the only operation supported is a SELECT * query, and it
curre
Zahid Khan <[EMAIL PROTECTED]> writes:
> I want to know that does ODBC executes all statement
> as simple query as i have't found any thing as
> parse/bind/execute messeges in ODBC case.
Probably; the ODBC code long predates the V3 protocol, and I don't think
it's been updated. But you're asking
hi
I want to know that does ODBC executes all statement
as simple query as i have't found any thing as
parse/bind/execute messeges in ODBC case.Or where can
i find the implementation of these messeges on ODBC
side
Thx
Zahid K
__
Do you Yahoo!?
On Fri, Sep 27, 2002 at 09:53:02AM -0700, Joe Conway wrote:
> It is in 7.3.
>
> If the return tuple definition is fixed:
> instead of:
> exec sp_myproc()
> go
> do
> select * from sp_myproc();
That's a great feature to have.
> If the return tuple definition is *not* fixed:
> do
>
Michael Meskes wrote:
> into. As far as I understand the problem, the application uses stored
> procedures for each and every select statement. Thus he needs his
> procedures to return the whole query result, which is not doable with
> our functions.
It is in 7.3.
If the return tuple definition
> -Original Message-
> From: Michael Meskes [mailto:[EMAIL PROTECTED]]
> Sent: 10 September 2002 20:42
> To: PostgreSQL Interfaces; PostgreSQL Hacker
> Subject: [HACKERS] ODBC problem/question
>
>
> Hi,
>
> I was just contacted by a customer about the
Hi,
I was just contacted by a customer about the SQLProcedureColumns call in
our odbc driver. It appears this call is undefined in the standard odbc
driver but is available in odbcplus. Could anyone please enlighten me
why this was forked and not merged into one driver? Is there a problem
when I
Hot sure if this is the right list, but. . .
On Mon, Sep 02, 2002 at 08:20:14PM -0400, Vince Vielhaber wrote:
> On Sat, 31 Aug 2002, Marc G. Fournier wrote:
>
> >
> > This is all in Vince's area ...
>
> Correction. You're not looking, it's in the users lounge. We've
> covered the button thing
On Sat, 31 Aug 2002, Marc G. Fournier wrote:
>
> This is all in Vince's area ...
Correction. You're not looking, it's in the users lounge. We've
covered the button thing already.
>
>
> On 23 Aug 2002, Greg Copeland wrote:
>
> > I must be blind. I don't see links to gborg anywhere on the deve
On Sat, 31 Aug 2002, Marc G. Fournier wrote:
>
> This is all in Vince's area ...
You're right. You don't see 'em.
>
>
> On 23 Aug 2002, Greg Copeland wrote:
>
> > I must be blind. I don't see links to gborg anywhere on the developer
> > or main site web pages. Perhaps more obvious a sister s
This is all in Vince's area ...
On 23 Aug 2002, Greg Copeland wrote:
> I must be blind. I don't see links to gborg anywhere on the developer
> or main site web pages. Perhaps more obvious a sister site link would
> be of value.
>
> The only link I found was under "User's Lounge" and then "Po
The current ODBC drivers on the website don't appear to work with recent
development.
I'm able to login, but immediately after it throws the error 'Blank'
with a large negative number above (-2^16 or so).
I don't have Visual C, so would it be possible for someone to build a
new (working) driver
Julian Mehnle wrote:
>
> Yeah, it does *not* exhibit the faulty CRLF<->LF conversion behavior.
> Is this a custom build of the ODBC driver done by you? Will the
> official driver be fixed soon?
I would commit the fix to cvs this week.
regards,
Hiroshi Inoue
http://w2422.nsk.ne.jp/~inoue
Hiroshi Inoue <[EMAIL PROTECTED]> wrote:
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
> > (beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
> > encoded database stored in a PostgreSQL 7.2.1 database runnin
Julian Mehnle wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> wrote:
> > Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > > Recently I tried to use the new 7.02.0001 Win32 ODBC driver
> > > in the new (beta) Unicode mode in conjunction with MS Access
> > > 2000 and a "UNICODE" encoded database stored in
"Julian Mehnle, Linksystem Muenchen" wrote:
>
> Hi all!
>
> Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
> (beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
> encoded database stored in a PostgreSQL 7.2.1 database running on a
> Linux system.
>
> I
Hiroshi Inoue <[EMAIL PROTECTED]> wrote:
> Julian Mehnle <[EMAIL PROTECTED]> wrote:
> > Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
> > (beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
> > encoded database stored in a PostgreSQL 7.2.1 database runni
Hi all!
Recently I tried to use the new 7.02.0001 Win32 ODBC driver in the new
(beta) Unicode mode in conjunction with MS Access 2000 and a "UNICODE"
encoded database stored in a PostgreSQL 7.2.1 database running on a
Linux system.
I noticed that when the "LF<->CRLF Conversion" option is *enable
Julian Mehnle wrote:
> [...] I made a patch.
>
> ==8<==snip==
> [word-wrapped patch]
> ==snip==>8==
Doh!
I swear I told my news reader not to word-wrap exactly this message,
but it wrapped it anyway.
Thanks for that.
I'll have to work around this by extracting all character variable data and
'hard coding' this into the SQL statement before I SQLExecute() the
statement. I had to do the same for ... Oracle (sorry for swearing).
Do you (or anyone else for that matter) know if/when UNICODE bindi
Andy Hallam wrote:
>
> Apologies if you think this mail is a little long-winded but I want to be as
> clear as possible on this.
>
> PostgreSQL - 7.1.3 (installed on Linux 2.4.2-2)
> PSQLODBC.DLL - 07.01.0007
> Visual C++ - 6.0
>
> I have a C++ app running on WINDOWS2000 and I am trying to use
Apologies if you think this mail is a little long-winded but I want to be as
clear as possible on this.
PostgreSQL - 7.1.3 (installed on Linux 2.4.2-2)
PSQLODBC.DLL - 07.01.0007
Visual C++ - 6.0
I have a C++ app running on WINDOWS2000 and I am trying to use
SQLBindParamater with a unicode (wcha
> -Original Message-
> From: Hiroshi Inoue [mailto:[EMAIL PROTECTED]]
> Sent: 24 September 2001 06:26
> To: Jean-Michel POURE
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> Tatsuo Ishii
> Subject: Re: [ODBC] UTF-8 support
>
>
> Jean-Michel POURE wrote:
> >
> > 3) Is there a way to qu
Hi Gowey,
Please post to pgsql-odbc list if the problem is ODBC
specific.
"Gowey, Geoffrey" wrote:
>
> Two problems (I've been holding back reporting until I ran into this
> second):
>
> Background: I'm trying to migrate an existing db from MS Sql 2K to pgsql by
> creating a DTS job.
>
> DB sys
Two problems (I've been holding back reporting until I ran into this
second):
Background: I'm trying to migrate an existing db from MS Sql 2K to pgsql by
creating a DTS job.
DB system info: NT 4 sp6a, MS SQL2K Regular, Pgsql ODBC driver 7.01.00.06.
First problem: The ODBC driver reports a colum
Jean-Michel POURE wrote:
>
> 3) Is there a way to query available encodings in PostgreSQL for display in
> pgAdmin.
Could pgAdmin display multibyte chars in the first place ?
regards,
Hiroshi Inoue
---(end of broadcast)---
TIP 2: you can get off a
-Original Message-
From: Jonathan Stanford
> Guys,
> I have some odd behaviour with VB6 & postgresql that may be a bug - I
would appreciate someone else > > replicating this; or any other suggestions
anyone might have.
[snip]
> PostgreSQL code:
> CREATE TABLE tb_search (
> session_id
> There is a TODO list at src/interfaces/odbc/TODO.txt which was last
> updated in 1998.
>
> Do any of the things in this list remain to be done?
> If not, perhaps the file should be removed.
File removed.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
There is a TODO list at src/interfaces/odbc/TODO.txt which was last
updated in 1998.
Do any of the things in this list remain to be done?
If not, perhaps the file should be removed.
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight htt
Hi EveryBody
When i connect to my database in windows98 (ODBC) to the
server in Linux, i can execute SELECT staments , but no INSERT or UPDATE
staments... the error 'Key Violation ..Connection is readonly , only select
staments are allowed' appears. the user was created wit
* Peter Eisentraut <[EMAIL PROTECTED]> [010324 17:35]:
> Tom Lane writes:
>
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > > I'll take the deafening silence as a NO?
> >
> > I was (a) waiting to see what Peter thought about it,
>
> Don't ask me, I don't know what this does...
>
> > and (b)
Tom Lane writes:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > I'll take the deafening silence as a NO?
>
> I was (a) waiting to see what Peter thought about it,
Don't ask me, I don't know what this does...
> and (b) wondering
> whether you'd actually tested to see that the built ODBC driver
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I'll take the deafening silence as a NO?
I was (a) waiting to see what Peter thought about it, and (b) wondering
whether you'd actually tested to see that the built ODBC driver does
something useful. I'm not eager to risk a post-RC1 change that could
t;>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 3/22/01, 4:02:45 PM, Larry Rosenman <[EMAIL PROTECTED]> wrote regarding Re:
> [HACKERS] odbc/UnixWare 7.1.1: No Go. :
>
>
> > OK
Can I get a go/nogo decision on whether these two functions can be #if'd
out for 7.1?
Thanks.
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 4:02:45 P
OK, it *IS* just a WARNING that the symbols are undefined.
SO, can we get the _fini/_init stuff commented/taken out for 7.1?
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
;<<<<<<<<<<<
On 3/22/01, 3:38:59 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > My question is WHY are we using -Bsymbolic and/or -z text anyway?
&
Larry Rosenman <[EMAIL PROTECTED]> writes:
> My question is WHY are we using -Bsymbolic and/or -z text anyway?
> These options don't appear to buy us anything but grief on SVR[45] ELF
> systems..
I have no idea what -z text means to your linker, but if it has a
-Bsymbolic option then it's a good
l Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 2:50:53 PM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding
Re: [HACKERS] odbc/UnixWare 7.1.1: No Go. :
> Larry Rosenman writes:
> > need to kill the _init too. Then we get other symbol
Larry Rosenman <[EMAIL PROTECTED]> writes:
> need to kill the _init too. Then we get other symbol issues, I think due
> to -Wl,z,text, but I'm not sure.
Um. This suggests that the real problem is a completely wrong approach
to linking the shared lib. On this evidence I'm not going to touch t
and before you ask, the _init and _fini NEED to go away.
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 1:00:08 PM, Larry Rosenman <[EMAIL PROTECTED]> wrot
Peter,
I'm not a GNU MAKE person, can you help here?
LER
>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 12:49:10 PM, Tom Lane <[EMAIL PROTECTED]> wrote re
ge <<<<<<<<<<<<<<<<<<
On 3/22/01, 12:23:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > Does this mean it's eligible
Larry Rosenman writes:
> using the following link, with the _init/_fini killed, works:
>
> cc -G *.o -L /usr/local/pgsql/lib -lpq -R/usr/local/pgsql/lib -lsocket -o
> libpsqlodbc.so.0.26
The libpq should definitely not be there, but if additional libraries such
as -lsocket make you happy then lo
write libm.so
> ilogb libm.so
> frexpl libm.so
> UX:ld: WARNING: Symbol referencing errors.
> rm -f libpsqlodbc.so.0
> ln -s libpsqlodbc.so.0.26 libpsqlodbc.so.0
> rm -f libpsqlodbc.so
>
;>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 12:23:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote regarding Re:
[HACKERS] odbc/UnixWare 7.1.1: No Go. :
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> > D
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Does this mean it's eligible to be fixed for 7.1?
We can talk about it anyway. Does removing the _fini alone make it work
for you, or do we have to remove _init too?
regards, tom lane
---(end of broad
Does this mean it's eligible to be fixed for 7.1?
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 11:05:29 AM, Tom Lane <[EMAIL PROTECTED]> wrote re
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It's supposed to work transparently for the library user. At least the
> _fini can probably be hooked in atexit, but the _init would probably have
> to be handled some other way.
The _fini does nothing, and I already made a hack to cover lack of the
In a very quick look I just made, I tend to agree with Tom, that the
whole non-gcc, non-windows stuff should go.
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On
>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 3/22/01, 10:16:03 AM, Peter Eisentraut <[EMAIL PROTECTED]> wrote regarding
> Re: [HACKERS] odbc/UnixWare 7.1.1: No Go.:
>
>
> > Larry Rosenman writes:
>
> &
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Larry Rosenman writes:
>> Why do WE define _fini?
> Because we need to 'fini' something, I suspect.
See src/interfaces/odbc/psqlodbc.c line 126. It doesn't look to me like
the _fini() does anything useful; could we take it out?
We do not actually
Can't we do something with atexit or other PORTABLE end stuff?
I'll look at it for 7.2.
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 3/22/01, 10:16:03 A
Larry Rosenman writes:
> cc -G -Wl,-z,text -Wl,-h,libpsqlodbc.so.0 -Wl,-Bsymbolic info.o bind.o columninfo.o
>connection.o convert.o drvconn.o environ.o execute.o lobj.o misc.o options.o
>pgtypes.o psqlodbc.o qresult.o results.o socket.o parse.o statement.o gpps.o tuple.o
>tuplelist.o dlg_spec
* Bruce Momjian <[EMAIL PROTECTED]> [010321 23:08]:
> Works fine here.
on a GCC platform, it does. I suspect this is a portability issue.
LER
>
>
> > Since I am playing with StarOffice, I figured I'd try --with-odbc,
> > current sources, except for the big Bruce commit I just saw :-)
> >
>
Works fine here.
> Since I am playing with StarOffice, I figured I'd try --with-odbc,
> current sources, except for the big Bruce commit I just saw :-)
>
>
> UX:tsort: INFO: psqlodbc.o
> UX:tsort: INFO: dlg_specific.o
> UX:tsort: INFO: convert.o
> UX:tsort: WARNING: Cycle in
Since I am playing with StarOffice, I figured I'd try --with-odbc,
current sources, except for the big Bruce commit I just saw :-)
UX:tsort: INFO: psqlodbc.o
UX:tsort: INFO: dlg_specific.o
UX:tsort: INFO: convert.o
UX:tsort: WARNING: Cycle in data
UX:tsort: INFO:
I figured that out, now to get the ODBC stuff totally right on the LINUX
side
of the box.
Do we work with unixODBC or the other one?
LER
>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<&l
* Alfred Perlstein <[EMAIL PROTECTED]> [010319 11:27] wrote:
> * Larry Rosenman <[EMAIL PROTECTED]> [010319 10:35] wrote:
> >
> > Is there any way to get just the ODBC RPM to install with OUT
> > installing the whole DB?
> >
> > I have a strange situation:
> >
> > StarOffice 5.2 (Linux) Runnin
* Larry Rosenman <[EMAIL PROTECTED]> [010319 10:35] wrote:
>
> Is there any way to get just the ODBC RPM to install with OUT
> installing the whole DB?
>
> I have a strange situation:
>
> StarOffice 5.2 (Linux) Running under FreeBSD Linux Emulation
> PG running NATIVE.
>
> I want the two to t
Is there any way to get just the ODBC RPM to install with OUT
installing the whole DB?
I have a strange situation:
StarOffice 5.2 (Linux) Running under FreeBSD Linux Emulation
PG running NATIVE.
I want the two to talk, using ODBC.
How do I make this happen?
LER
--
Larry Rosenman
I have backed out the changes to ODBC that removed compatibility with
<6.4 servers, so the 7.1 ODBC code still supports the older servers.
I have changed the dialog box from "6.4+" to "7.X,6.4+" to make it less
confusing for users.
Is that ODBC protocol dialog box needed? Can the client auto-det
The 7.1 PostgreSQL ODBC client interface will no longer be able to talk
to PostgreSQL servers earlier than 6.4. The backward compatibility code
has been removed.
Does anyone want such compatibility?
(FYI, libpq and all interfaces based on it can't talk to such servers
either.)
--
Bruce Mom
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > Does removing pre-6.4 code improve the status ?
>
> Yes, it does (IMHO anyway) because it removes a configuration option
> that is confusing new users.
Right. There's even an idea(not mine) to remove
the option by automatically
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> Does removing pre-6.4 code improve the status ?
Yes, it does (IMHO anyway) because it removes a configuration option
that is confusing new users. The odds that someone will want to use 7.1
ODBC with a pre-6.4 server seem very small to me, while we do
> > -Original Message-
> > From: Bruce Momjian
> > Sent: Sunday, February 11, 2001 11:01 AM
> > To: PostgreSQL-development
> > Subject: [HACKERS] ODBC backward versions
> >
> >
> > I checked the logs, and we released the new 6.4 backend
> -Original Message-
> From: Bruce Momjian
> Sent: Sunday, February 11, 2001 11:01 AM
> To: PostgreSQL-development
> Subject: [HACKERS] ODBC backward versions
>
>
> I checked the logs, and we released the new 6.4 backend protocol on
> 1998-10-30. That
I checked the logs, and we released the new 6.4 backend protocol on
1998-10-30. That was 2.5 years ago.
We normally allow older clients to communicate with newer servers, but
often we don't support newer clients talking to older servers, sometimes
even servers one release in the past. The reaso
I installed the ODBC driver for Postgre, and linked in a table which has a
Serial field for the primary key. In MS Access, the type is shown as just
"Number (long integer)".
When I try to add new records to my database in Access, I don't put anything
into the key field because the server is suppo
"Steve Shaffer" <[EMAIL PROTECTED]> writes:
> Pgsql v7.1 beta4
> ODBC v6.50.00.00
> RedHat v6.2
> I upgraded from 7.03 to 7.1 beta4 yesterday & see the following problem.
> After the upgrade, applications like Crystal Reports, MS Query, Brio, etc.
> now do not see the catalog of tables
Me too ! :-))
Same problem on Debian-unstable + Oliver Elphick's beta4 packages + UnixODBC
2.0.3
Database still can be accessed through ODBC in you don't need the tables list
: tried from the stats package R through RODBC : sqlTables() fails, sqlQuery()
works. So the problem is probably an inte
I have a problem with 7.1 beta 4
Setup :
Debian 2.3(?) (unstable)
Kernel 2.18pre23 (the stock Debian kernel)
PostgreSQL 7.1beta4 as packaged for Debian by Oliver Elphick
unixODBC 2.0.3 compiled from unixODBC.org's sources against the installed and
working PG 7.1b4.
The problem is that an ODBC co
Yes, I have the same problem...
pgaccess also can't see any Views...
"Steve Shaffer" <[EMAIL PROTECTED]> escreveu nas notícias de
mensagem:[EMAIL PROTECTED]
>
> Developers,
>
> Pgsql v7.1 beta4
> ODBC v6.50.00.00
> RedHat v6.2
>
> I upgraded from 7.03 to 7.1 beta4 yesterday & see the f
Developers,
Pgsql v7.1 beta4
ODBC v6.50.00.00
RedHat v6.2
I upgraded from 7.03 to 7.1 beta4 yesterday & see the following problem.
After the upgrade, applications like Crystal Reports, MS Query, Brio, etc.
now do not see the catalog of tables and fields in the database, login is
throu
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: 16 January 2001 16:50
> To: Dave Page
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: [HACKERS] ODBC Driver int8 Patch
>
>
> As I remember, the problem is that this makes us mat
As I remember, the problem is that this makes us match the ODBC v2 spec,
but then we would not match the v3 spec. Is that correct?
[ Charset ISO-8859-1 unsupported, converting... ]
> Hi,
>
> It was suggested that I post this patch here as no notice was taken of it
> when posted to interfaces!
Hi,
It was suggested that I post this patch here as no notice was taken of it
when posted to interfaces!
This fixes problems with int8 columns which are reported by the driver as
SQL_BIGINT rather than SQL_CHAR as per the ODBC v2 spec. Specifically, I
have had problems with MS ADO - any queries
I am curious as to where the newest ODBC driver source is -- I retrieved
/src/interfaces/odbc from CVS, but it appeared to only be version
6.40.0009 and was lacking the Visual C++ workspace/project files that
were in the 6.50. release zip file on the FTP server.
Thanks
Michael Fork - CCNA
94 matches
Mail list logo
