Byron,
Thanks for the driver. It took care of my problem as long as the 6.2
protocol was used. Whenever I selected the 6.3 or latest check boxes, I get
the following error:
Connectivity error: Unsupported frontend protocol
I went back to my original driver and verified that I could get it to work
with the 6.2 protocol option both selected and un-selected.
Here's the CommLog output when I selected the 6.3 protocol:
CONN ERROR: func=SQLSetConnectOption, desc='fOption=112, vParam=4096',
errnum=5, errmsg='Driver does not support setting this connect option'
------------------------------------------------------------
henv=96341980, conn=95289464, status=0, num_stmts=16
sock=96338052, stmts=96338092, lobj_type=-999
---------------- Socket Info -------------------------------
socket=-1, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=95295756, buffer_out=95299856
buffer_filled_in=0, buffer_filled_out=0, buffer_read_in=0
conn=95289464, SQLDriverConnect( in)='DSN=PostgreSQL ODBCtest;UID=;PWD=;',
fDriverCompletion=1
DSN info: DSN='PostgreSQL
ODBCtest',server='alpha',port='5432',dbase='odbctest',user='',passwd=''
readonly='0',protocol='6.2',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings=''
translation_dll='',translation_option=''
conn=95289464, SQLDriverConnect(out)='DSN=PostgreSQL
ODBCtest;DATABASE=odbctest;SERVER=alpha;PORT=5432;UID=mds;PWD=*deleted*;READ
ONLY=0;PROTOCOL=6.3;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTE
MTABLES=0;CONNSETTINGS='
Global Options: Version='06.30.0250', fetch=100, socket=4096,
unknown_sizes=0, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=0, unique_index=0, use_declarefetch=1
text_as_longvarchar=0, unknowns_as_longvarchar=0,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings=''
ERROR from backend during authentication: 'Unsupported frontend protocol.'
CONN ERROR: func=SQLDriverConnect, desc='Error from CC_Connect', errnum=10,
errmsg='Unsupported frontend protocol.'
------------------------------------------------------------
henv=96341980, conn=95289464, status=0, num_stmts=16
sock=96338052, stmts=96338092, lobj_type=-999
---------------- Socket Info -------------------------------
socket=35, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=95295756, buffer_out=95299856
buffer_filled_in=32, buffer_filled_out=0, buffer_read_in=32
> -----Original Message-----
> From: Byron Nikolaidis [mailto:byronn@insightdist.com]
> Sent: Wednesday, September 16, 1998 2:16 PM
> To: Mark D. Seeley
> Subject: Re: [INTERFACES] psqlodbc bug or something else?
>
>
>
>
> Mark D. Seeley wrote:
>
> > conn=95289464, query='declare SQL_CUR95303956 cursor for SELECT * FROM
> > mds.medical_bills WHERE 1=0'
> > ERROR from backend during send_query: 'ERROR: parser: parse error at or
> > near "."'
> >
> > mds is the username for the connection and medical_bills is the selected
> > table. The SELECT statement also produces the error in psql.
> >
> > The question is where and why is the user name "mds" being
> added as a prefix
> > to the table name "medical_bills" -- is this something related
> to the odbc
> > driver or do I need to look elsewhere?
> >
>
> Ahhh, the dreaded username.tablename... The thing is, in all the driver
> functions, such as SQLTables (this was called just prior to the
> error), the
> owner name is set to blank on purpose because we have had this
> trouble before
> with Access. Access was insisting on using this syntax if an
> owner name is
> returned.
>
> So, for your case, it looks like it might be the SQL_USER_NAME
> function. Foxpro
> must be pre-pending that data to the table name.
>
> Here's a version of the driver which returns blank for this call.
> Give it a try
> and let me know. Unzip to \windows\system.
>
>
> Byron
>
>
>
