quickfix-users

[Quickfix-users] Sql Server ODBC issues

[George M. C. <geo...@qu...>]

Hi, this is an update on my earlier issue.
   I am using the ODBC log and store factories built from the 
quickfix_vs8.sln in version 1.12.4 of quickfix. I am using SQL Server, 
and my ODBC DataSource Administrator say that those drivers are version 
2000.85.1117.00.

I am using these connection strings:

OdbcLogUser=xx
OdbcLogPassword=yy
OdbcStoreUser=xx
OdbcStorePassword=yy
OdbcLogConnectionString="DATABASE=quickfix;DRIVER={SQL 
Server};SERVER=DATASERVER;"
OdbcStoreConnectionString="DATABASE=quickfix;DRIVER={SQL 
Server};SERVER=DATASERVER;"

I turned on ODBC trace logging. It shows the following information codes 
when I try to connect:

DIAG [01S00] [Microsoft][ODBC Driver Manager] Invalid connection string 
attribute (0)

DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Changed 
database context to 'dbMARKET'. (5701)

DIAG [01S00] [Microsoft][ODBC Driver Manager] Invalid connection string 
attribute (0)

DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Changed 
database context to 'dbMARKET'. (5701)

When subsequent SQL statements are executed against this connection, it 
blows up with the interop error I posted before, because, I believe, the 
table names are not fully qualified. I could not figure out why the 
database context is getting changed to dbMarket, and not quickfix, so I 
chose to address the problem by prefixing every table name in 
OdbcStore.cpp and OdbcLog.cpp with "quickfix.." This fixed that problem, 
and I can now set up an acceptor session, at least.

You might consider using the fully qualified table names in case someone 
like me runs into this ODBC connection issue in the future. I think it 
is good practice to use fully qualified names for db objects in general 
isnt it?

There are a couple of other issues too:

-From time to time the trace log shows that inserts into messages_log 
are failing because a NULL is being inserted in the SESSION_QUALIFIER 
column, which is defined as NOT NULL in the sql create script.

- The columns MESSAGES_LOG.TEXT and MESSAGES.MESSAGE are, at least in my 
database, being truncated - only the section of the text "8=FIX.4.4" 
exists. I see that the sql string is being built with a lot of 
backslashes - is that some kind of MYSQL escape char that MSSQL is not 
enjoying?

thx
George

Re: [Quickfix-users] Sql Server ODBC issues

[Oren M. <or...@qu...>]

Is there a reason you are not providing a DATABASE=3Dquickfix into the
connection string?

--oren

> Hi, this is an update on my earlier issue.
>    I am using the ODBC log and store factories built from the=20
> quickfix_vs8.sln in version 1.12.4 of quickfix. I am using SQL Server,=20
> and my ODBC DataSource Administrator say that those drivers are
version=20
> 2000.85.1117.00.
>=20
> I am using these connection strings:
>=20
> OdbcLogUser=3Dxx
> OdbcLogPassword=3Dyy
> OdbcStoreUser=3Dxx
> OdbcStorePassword=3Dyy
> OdbcLogConnectionString=3D"DATABASE=3Dquickfix;DRIVER=3D{SQL=20
> Server};SERVER=3DDATASERVER;"
> OdbcStoreConnectionString=3D"DATABASE=3Dquickfix;DRIVER=3D{SQL=20
> Server};SERVER=3DDATASERVER;"

Re: [Quickfix-users] Sql Server ODBC issues

[Oren M. <or...@qu...>]

> You might consider using the fully qualified table names in case
someone=20
> like me runs into this ODBC connection issue in the future. I think it=20
> is good practice to use fully qualified names for db objects in
general=20
> isnt it?

We don't fully qualify because some people may not want to use a
database called quickfix.  If someone puts the tables in the default
context, then that may very well be their intention.  The main issue is
that we are crashing instead of providing a proper ConfigException.
This was due to a ConfigError pointer being thrown instead of a
reference.  This has been fixed and QuickFIX will now report a
connection problem in this case (due to being unable to populate the
cache).

> There are a couple of other issues too:
>=20
> -From time to time the trace log shows that inserts into messages_log=20
> are failing because a NULL is being inserted in the SESSION_QUALIFIER=20
> column, which is defined as NOT NULL in the sql create script.

This column should be nullable.  We will fix it.

> - The columns MESSAGES_LOG.TEXT and MESSAGES.MESSAGE are, at least in
my=20
> database, being truncated - only the section of the text "8=3DFIX.4.4"=20
> exists. I see that the sql string is being built with a lot of=20
> backslashes - is that some kind of MYSQL escape char that MSSQL is not=20
> enjoying?

I believe this is a result of MSSQL tools interpreting the SOH character
as some sort of end of string.  The correct values are actually in
there.

-oren