Обсуждение: ODBC - MSAccess W95/98
Hi there, (this time it is posted to interface also.) thanks a lot for the hints so far. this is my pg_hba.conf: ------------------------------------ local all trust host all 127.0.0.1 255.255.255.255 trust host all 192.168.0.0 255.255.255.0 trust ------------------------------------ what I understand is: 3rd line says all stations 192.168.0.x are allowed Now I try to be careful about the PsqlODBC FAQ from insightdigest: I remove my User- and System-DSN from 32Bit-ODBS as well as my SQL-Server kk1 from ODBC. I create a new System DSN: PostgeSQL Driver Version 6.40.0004 Data Source: PostgreSQL Database: kk1 (still exist, just tested on capella) Server: 192.168.0.3 Username: www Port: 5432 Password: still secret then I (re)set the advanced driver options to default. advanced datasourceoptions (untouched i hope) all switches off, protocol 6.4 back in system dsn i click on ok. I delete c:\*.log and enter the tracing section, where i request tracing all the time to c:\SQL.LOG. After <start tracing now> I close 32Bit-ODBC and move over to ODBC. There I <add driver> and select <SQL Server>: Datenquellenname: kk1 (datasourcename) Beschreibung: kk testet (description) Server: 192.168.0.3 (entered by typing, not selected from the list) Netzwerkadresse: (Standart) (networkadress) Netzwerkbibliothek: (Standart) (networklibrary) with <options> I enter the databasename kk1 I quit this using ok and find the driver kk1 under the list of datasources. then I have to wait the remaining 21 minutes for my backup to come ready and will restart my computer (just in case). Meanwhile: I fed the database kk1 as user www on capella (192.168.0.3 running a fairly new linux version 2.0.35 from suse 5.3 (did I tell) ) with 2 records, investigated the whereabouts of a signaturefile for one of the users and set up a new cofee, wich has nothing to do with the problem. The computer I'm working on is 192.168.0.33 (Muenchen) running W95. It is also mentioned in /etc/hosts on capella. nslookup of my station there gets a correct answer from our nameserver arktur (192.168.0.1). LABEL: Try2 starting m$access, creating a new database. Tabelle - einbinden ( include table? ), file format: <SQL-Datenbank> datasource: kk1 Anmeldename: www (does it matter: www or WWW?) Kennwort: stillsecret I start tcpdump on capella 2 times for traffic to capella and muenchen and press <OK> in Access. that is what I get: Error Message translated: ---------------------------------------------------------------- Connection failed: SQL State: '01000' SQL Server-Error: -1 [Microsoft][ODBC SQL Server Driver][dbnmp3]ConnectionOpen (sopen()), Connection failed: SQL State: '08001' SQL Server-Error: 0 [Microsoft][ODBC SQL Server Driver]Connection could not be established. ---------------------------------------------------------------- the file c:\sql.log contains 0 bytes and there is no other *.log tcpdump to my station (muenchen ....33) contains no significant packets. tcpdump to capella (....3) contains no significant packets. okay, I retry starting from 32Bit-ODBC thistime using capella as the servername and redefine the logsettings. in ODBC I change servername to capella and networkadress to 192.168.0.3. then I go to Label: Try2 The errormessage ist the same as in try 1 and the tcpdumpfiles do not contain useful information for me, except that I would expect more packets there. some time later: after trying this and that i got a mayby hintful message from tcpdump. It is from capella to my station: 15:10:30.710266 192.168.0.3.139 > 192.168.0.33.1027: P 95:134(39) ack 237 win 16368 >>> NBT Packet NBT Session Packet Flags=0x0 Length=35 SMB PACKET: SMBopenX (REPLY) SMB Command = 0x2D Error class = 0x2 Error code = 4 Flags1 = 0x80 Flags2 = 0x1 Tree ID = 114 Proc ID = 7947 UID = 100 MID = 16643 Word Count = 0 SMBError = ERRSRV - ERRaccess (The requester does not have the necessary access rights within the specified context for the requested function. The context is defined by the TID or the UID.) smbvwv[]= Com2=smb_bcc=0 --------------------------------------------- throughout the whole dump it is preceeded by this: (muenchen to capella): 15:10:31.330266 192.168.0.33.1027 > 192.168.0.3.139: P 322:407(85) ack 173 win 8109 >>> NBT Packet NBT Session Packet Flags=0x0 Length=81 WARNING: Short packet. Try increasing the snap length (44) SMB PACKET: SMBopenX (REQUEST) SMB Command = 0x2D Error class = 0x0 Error code = 0 Flags1 = 0x0 Flags2 = 0x1 Tree ID = 114 Proc ID = 7947 UID = 100 MID = 16899 Word Count = 15 smbvwv[]= Com2=0xFF Off2=0 Flags=0x1 Mode=0x42 SearchAttrib=HIDDEN SYSTEM DIR Attrib= Time=Mon Sep 8 07:53:48 2031 OFun=0x1 Size=0 TimeOut=0 Res=0x0 smbbuf[]= Path= (DF) ------------------------------------------------ Does "WARNING: Short packet. Try increasing the snap length (44)" warn about something (serious). and still there is an empty c:\sql.log and no other *.log. the logfile of postmaster (running -d 6) does not mention anything at all during the period I try to connect. hoping for help, Karsten Kaus
Here a few items which you can check which I do not see mentioned here.
1. Are you using the -i option when you start the postmaster?
2. Is the user set up in the DSN established on the server side/
3. Are the protocols compatable. (6.4 server vs 6.4 driver setting)
Have faith. We'll get the configuration worked out.
Karsten Kaus wrote:
> Hi there,
>
> (this time it is posted to interface also.)
>
> thanks a lot for the hints so far.
>
> this is my pg_hba.conf:
> ------------------------------------
> local all trust
> host all 127.0.0.1 255.255.255.255 trust
> host all 192.168.0.0 255.255.255.0 trust
> ------------------------------------
> what I understand is: 3rd line says all stations 192.168.0.x
> are allowed
>
> Now I try to be careful about the PsqlODBC FAQ from insightdigest:
> I remove my User- and System-DSN from 32Bit-ODBS as well as
> my SQL-Server kk1 from ODBC.
> I create a new System DSN:
> PostgeSQL Driver Version 6.40.0004
> Data Source: PostgreSQL
> Database: kk1 (still exist, just tested on capella)
> Server: 192.168.0.3
> Username: www
> Port: 5432
> Password: still secret
>
> then I (re)set the advanced driver options to default.
> advanced datasourceoptions (untouched i hope)
> all switches off, protocol 6.4
> back in system dsn i click on ok.
>
> I delete c:\*.log and enter the tracing section, where i request
> tracing all the time to c:\SQL.LOG.
> After <start tracing now> I close 32Bit-ODBC and move over to ODBC.
> There I <add driver> and select <SQL Server>:
> Datenquellenname: kk1 (datasourcename)
> Beschreibung: kk testet (description)
> Server: 192.168.0.3 (entered by typing, not selected from the list)
> Netzwerkadresse: (Standart) (networkadress)
> Netzwerkbibliothek: (Standart) (networklibrary)
>
> with <options> I enter the databasename kk1
> I quit this using ok and find the driver kk1 under the
> list of datasources.
> then I have to wait the remaining 21 minutes for my backup to come ready
> and
> will restart my computer (just in case).
>
> Meanwhile:
> I fed the database kk1 as user www on capella (192.168.0.3 running
> a fairly new linux version 2.0.35 from suse 5.3 (did I tell) ) with 2
> records,
> investigated the whereabouts of a signaturefile for one of the users and
> set up a new cofee, wich has nothing to do with the problem.
>
> The computer I'm working on is 192.168.0.33 (Muenchen) running W95.
> It is also mentioned in /etc/hosts on capella.
> nslookup of my station there gets a correct answer from our nameserver
> arktur (192.168.0.1).
>
> LABEL: Try2
> starting m$access, creating a new database.
> Tabelle - einbinden ( include table? ), file format: <SQL-Datenbank>
> datasource: kk1
> Anmeldename: www (does it matter: www or WWW?)
> Kennwort: stillsecret
>
> I start tcpdump on capella 2 times for traffic to capella and muenchen
> and
> press <OK> in Access.
> that is what I get:
> Error Message translated:
> ----------------------------------------------------------------
> Connection failed:
> SQL State: '01000'
> SQL Server-Error: -1
> [Microsoft][ODBC SQL Server Driver][dbnmp3]ConnectionOpen (sopen()),
> Connection failed:
> SQL State: '08001'
> SQL Server-Error: 0
> [Microsoft][ODBC SQL Server Driver]Connection could not be established.
> ----------------------------------------------------------------
> the file c:\sql.log contains 0 bytes and there is no other *.log
>
> tcpdump to my station (muenchen ....33) contains no significant packets.
> tcpdump to capella (....3) contains no significant packets.
>
> okay, I retry starting from 32Bit-ODBC thistime using capella as the
> servername
> and redefine the logsettings.
>
> in ODBC I change servername to capella and networkadress to 192.168.0.3.
> then I go to Label: Try2
>
> The errormessage ist the same as in try 1 and the tcpdumpfiles do not
> contain useful information for me, except that I would expect more
> packets there.
>
> some time later:
> after trying this and that i got a mayby hintful message from tcpdump.
> It is from capella to my station:
>
> 15:10:30.710266 192.168.0.3.139 > 192.168.0.33.1027: P 95:134(39) ack
> 237 win 16368
> >>> NBT Packet
> NBT Session Packet
> Flags=0x0
> Length=35
>
> SMB PACKET: SMBopenX (REPLY)
> SMB Command = 0x2D
> Error class = 0x2
> Error code = 4
> Flags1 = 0x80
> Flags2 = 0x1
> Tree ID = 114
> Proc ID = 7947
> UID = 100
> MID = 16643
> Word Count = 0
> SMBError = ERRSRV - ERRaccess (The requester does not have the
> necessary access rights within the specified context for the
> requested function. The context is defined by the TID or the UID.)
> smbvwv[]=
> Com2=smb_bcc=0
> ---------------------------------------------
>
> throughout the whole dump it is preceeded by this: (muenchen to
> capella):
> 15:10:31.330266 192.168.0.33.1027 > 192.168.0.3.139: P 322:407(85) ack
> 173 win 8109
> >>> NBT Packet
> NBT Session Packet
> Flags=0x0
> Length=81
> WARNING: Short packet. Try increasing the snap length (44)
>
> SMB PACKET: SMBopenX (REQUEST)
> SMB Command = 0x2D
> Error class = 0x0
> Error code = 0
> Flags1 = 0x0
> Flags2 = 0x1
> Tree ID = 114
> Proc ID = 7947
> UID = 100
> MID = 16899
> Word Count = 15
> smbvwv[]=
> Com2=0xFF
> Off2=0
> Flags=0x1
> Mode=0x42
> SearchAttrib=HIDDEN SYSTEM DIR
> Attrib=
> Time=Mon Sep 8 07:53:48 2031
> OFun=0x1
> Size=0
> TimeOut=0
> Res=0x0
> smbbuf[]=
> Path=
>
> (DF)
> ------------------------------------------------
> Does "WARNING: Short packet. Try increasing the snap length (44)" warn
> about
> something (serious).
>
> and still there is an empty c:\sql.log and no other *.log.
> the logfile of postmaster (running -d 6) does not mention anything at
> all during
> the period I try to connect.
>
> hoping for help,
> Karsten Kaus