Re: [VW 7.3.1] ODBCConnection



Thomas,

I can't thank you enough. This is exactly what I needed.

I played around with a few combinations on the connection string and
eventually got it right. But I was getting an error: User not associated
with a trusted SQL Server connection. So, I googled the error string and
found that I needed to open up authentication to SQL Server and Windows NT,
which I did using the Enterprise Manager.

But I still got the error message. So, I dug some more. On
www.windowsitpro.com, I read a response to the solution above that mentioned
using a utility called cliconfg.exe. Then by putting NamedPipes ahead of
TCP/IP (don't ask me what this means), I finally got it to work.

Admittedly, my 20 year career has been blissfully ignorant of databases in
general and I am now forced to broach the subject, but this last little bit
of solution seems terribly obscure.

At any rate, thanks again. I now have direct connection to an SQL Server
database w/o defining a data source.

Regards,
Charlie

"Thomas Brodt" <thomas.brodt@xxxxxxxxxx> wrote in message
news:43311137@xxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Charlie,
>
> Well, there are differences for database connects. Each one uses different
> informations in its connect strings).
>
> Postgres Connect using the PostgresEXDIConnection doesn't need a
> datasource (which is ODBC specific, not native postgres) nor does it need
> any database specific odbc drivers. You can directly connect to postgres
> using a socket connection which is not common for all database clients.
> Other databases use vendor specific database client dlls, as e.g. Oracle,
> Sybase, DB2, informix and others.
>
> alternatively you can connect to postgres (or any other database that
> provides odbc drivers) using an odbc driver. then you are bound to the
> odbc protocol which should be a unifying standard across different
> database vendors. Communication then goes from vw via this driver to the
> database, not directly as above. odbc is a translation layer between the
> application that uses odbc and the vendor specific database protocol.
>
> Normally you define an odbc data source for a connection to a whatever
> database. This name can then be used, because the odbc driver manager is
> then responsible for translation of this name to make a connection. It
> looks up all the settings and specifics defined for the data source, which
> includes what database type and driver is being used.
>
> the need to define a datasource for odbc can be omitted if you provide all
> settings - that you make when defining a data source in the driver
> manager - in the connect string.
>
> a possible connect to Informix via odbc without a data source is e.g.
> "DRIVER={IBM INFORMIX 3.82 32 BIT};DB=ultimate;UID=whoever;PWD=secret;
> SERVER=ol_serv1;HOST=serv1;SERVICE=turbo;PRO=onsoctcp;
> TDLL=C:\Programme\Informix\Client-SDK\bin\igo4n304.dll;"
>
> This defines all settings normally configured for a datasource. the name
> of the driver is that one that is displayed when choosing the database
> type in odbc.
>
> in VW, the class ODBCConnection uses a different connection scheme if
> DRIVER={ is given in the connect string, using SQLDriverConnect instead of
> SQLConnect. (See method useDriverConnect: there)
>
> Using MS SQLServer, it sould be DRIVER={SQL Server};DB=xxx;UID=......
>
> Providing this as connect string for an odbc connection should connect
> directly to SQLserver without the need for a defined DSN.
>
> We currently connect only to Informix (via ODBC driver) using this scheme,
> so I cannot provide any specifics for SQL Server, just that it should work
> as it does for Informix. We never define a DSN for our access to Informix,
> we just use the way described above.
>
> Thomas
>
> BTW: Even StroeForSQLServer should be able to connect using driverConnect
> without a defined DSN if the settings string is set up correctly.
>
> Charlie Adams schrieb:
>> OK, I've browsed the vwnc mailing list archives and apparently that is
>> just the way StoreForSQLServer works. You must declare a data source
>> through Windows' ODBC Data Source Administrator. PostgreSQL opens a
>> socket and converses directly. This must be the lone exception for
>> Windows-based DB access.
>>
>> What bothers me is that it was so difficult to divine.
>>
>> "Charlie Adams" <c-adams@xxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:43302363$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>>>In looking at PostgreSQLEXDIConnection, it would appear to do what I
>>>need. It takes an environment string, ex. 'hostName:port_dBName', and
>>>connects straight through to the machine -- no data source required.
>>>
>>>Is it possible to achieve this behavior with an ODBCConnection? It seems
>>>to only work with data sources.
>>>
>>>"Thomas Brodt" <thomas.brodt@xxxxxxxxxx> wrote in message
>>>news:432fc8cb$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
>>>
>>>>AFAIK, the DRIVER must be given in {} and it must be first in the
>>>>parameter string, so you should begin with 'DRIVER={don't know what SQL
>>>>Server has to look like};UID=.....'.
>>>>
>>>>You should also verify that in odbcconnection you use the path using the
>>>>SQL*Driver*Connect call, not the regular SQLConnect which uses data
>>>>source names.
>>>>
>>>>HTH
>>>>Thomas
>>>>
>>>>Charlie Adams schrieb:
>>>>
>>>>>In WinXP Pro and VW 7.3.1, it appears that I cannot create a valid
>>>>>ODBCConnection object without building an ODBC Data Source using the
>>>>>ODBC Data Source Administrator from Windows Admin Tools. Is that right?
>>>>>
>>>>>I want to connect to my version 7.0 SQL Server directly and attach to a
>>>>>database there. But it seems I must build the interim data source
>>>>>object to get there. My customer chafes at this saying his Java program
>>>>>uses a connection string of the sort:
>>>>>
>>>>>Driver=SQL
>>>>>Server;Server=myMachine;Database=SomeDBName;Uid=myUserID;Pwd=aPsswrd
>>>>>
>>>>>and this negates the need to define a data source. I don't see the
>>>>>magic I need from the DatabaseAppDevGuide.pdf.
>>>>>
>>>
>>>
>>

.



Relevant Pages

  • Re: Changing Connection String programmatically
    ... Connection strings of different years can be stored in app.config ... is declared in MyDataset.Designer.cs as private, ... every year we will create new database. ... If you are storing connnection string information related to additional ...
    (microsoft.public.sqlserver.connect)
  • Re: MS Access looks for .mdb rather than Progress schema
    ... # Same query previously worked in Progress 8.x using SQL89. ... This entry allows you to keep your existing code written with the ODBC ... BTW, if you put all of the connect information into the connect string, ... I also tried putting the whole thing in the connection string: ...
    (microsoft.public.access.modulesdaovba)
  • Send Form results to database error
    ... ' Send results to the database. ... ' myConnString = Connection string to database. ... ' myConnection = The database connection object. ...
    (microsoft.public.access.forms)
  • Re: User count
    ... Dim colUsers as New Collection ... Dim sCompName as string ... or back it up, or something, then take a look at the use of the "Connection ... Create a table in the front-end database, ...
    (microsoft.public.access.formscoding)
  • Re: Ada DB bindings and APQ
    ... >>I didn't like the use of handles for database objects. ... > will ensure that the connection will not go away until at least one query ... > things which can be made with a connection. ... That is different to ODBC. ...
    (comp.lang.ada)