ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Crystal Reports, ODBC & Access >> ODBC General Issues >> No 64-bit ODBC for PSQL
http://www.istechforum.com/YaBB.pl?num=1236260809

Message started by GasGiant on 03/05/09 at 06:46:49

Title: No 64-bit ODBC for PSQL
Post by GasGiant on 03/05/09 at 06:46:49

Recently, two IS Tech customers have had trouble connecting to ODBC because the system DSN for Pervasive does not show up in Data Sources. As it turns out, both locations had updated to Win2008 with 64-bit. Last night I found the answer to the problem on the Tek Tips forum. Simply put, Pervasive 10.10, though it has a much improved and built in ODBC, has no 64 bit ODBC. The 32-bit ODBC support must be installed as a separate function from the Pervasive install. Here is the quote from tek-tips.com:

"You'll need to use the 32 bit ODBC Administrator. It's in the C:\WINDOWS\SYSWOW64 directory. You can also create the DSN/DBN through the PCC.
The 64 bit PSQL engine is 64 bit for Btrieve only. The ODBC is still 32 bit. "

Another issue is that you must be an "elevated administrator" for Win2008/Vista in order to perform system DSN functions.

Title: Re: No 64-bit ODBC for PSQL
Post by kkmfg on 03/05/09 at 06:57:09

Tell me again why people insist on using over priced garbage like PervasiveSQL instead of PostgreSQL?

Title: Re: No 64-bit ODBC for PSQL
Post by GasGiant on 03/05/09 at 07:28:33

Again? Someone came up with a good reason previously? Yeah, I didn't think so.

Title: Re: No 64-bit ODBC for PSQL
Post by kkmfg on 03/05/09 at 08:53:03

I suppose I was just using it as an expression. There is a good reason: TAS basically only supports btrieve. You know, that database access product from the 80's that some people are still torturing themselves with. There are TAS versions which support SQL now but I'm pretty sure it's the one ISTech isn't using. Quite frankly btrieve is an idea that made sense 20-25 years ago and quit making sense about 10-15 years ago.

I wanted to write a wrapper around btrieve calls and translate them to postgresql. I even got some of it done. But the btrieve API is so old fashioned and stupid that I couldn't bring myself to go through with it. Essentially all records are stored as one big binary blob. I'd have to store them as blobs in postgresql and then nobody would be able to directly access any information with SQL. Oh, I could try to reverse engineer how btrieve stores all its data in the blob but that would slow down database access. There might be some way of storing it as a blob but with metadata about the structure and then create triggers or something and maybe store the info twice, once as a blob for btrieve and then again as seperate data. Sounds like a mess doesn't it? The only reason I'd do it is to spite Pervasive for dragging this dead horse into the 21st century... But that's not that good of a reason.