Problems with connecting to Sqlbase by SQL.INI

[tfahey]

Here is an odd thing: We connect to dozens of SqlBase Databases that are hosted on several servers. So to do that we use the 'serverpath' variables in the client section of the SQL.INI file. One server is allowed a wildcard ('IP address/*'), while all the other must list the databases by name under their own IP addresses.

TD 6.3 has problems reading the non wildcard entries. In fact I can only get it to work if I use the Database Explore to 'identify' and connect to the database I want to query. Once I use the database explorer, I can open my program and connect to that particular database. The development environment crashes otherwise.

Summary: TD 6.3 is only working with wildcard entries in the SQL.ini file.

Sample of our normal SQL.INI client section:
serverpath=serverx,10.0.85.15,3306/*
serverpath=Serv2012,10.0.85.15,2155/hbhab13,accbase5,hbbase5,hbhall,hbjones
serverpath=serv117,10.0.85.30,2155/hbral1,accral1

Sample that works:
serverpath=serverx,10.0.85.15,3306/*

Thanks,
Tom Fahey
HAB Inc

[thomas]

I can confirm this problem

[Mike Vandine]

Hi Tom,

I will be checking into this. A quick clarification:

Do you really have two instances of SQLBase running on the same server (same IP address - 10.0.85.15)?:

serverpath=serverx,10.0.85.15,3306/*
serverpath=Serv2012,10.0.85.15,2155/

[Mike Vandine]

In addition, can you connect to databases using SQLTalk from either the TD directory or the TD\SQLBase directory?

[Mike Vandine]

Hi Tom,

Can you please confirm if you can use SQLTalk in the TD6.3 directory using the sql.ini file? Here is my sql.ini files:

TD6.3:

[win32client]
clientname=REM7MV-NJ12
clientruntimedir="C:\TD6.3"

[win32client.dll]
comdll=sqlws32

[win32client.ws32]
serverpath=SB63,127.0.0.1,2156/*
serverpath=sb117,127.0.0.1,2155/stblobtest

TD6.3\sqlbase:

[dbntsrv]
dbname=ISLAND
dbname=SBTASK
ANSIJoinSyntax=1
centurydefaultmode=1

NamedPipes=LocalOnly
servername=SB63
dbdir=C:\TD6.3\sqlbase
tempdir=C:\TD6.3\sqlbase
consoleport=2697
DBNAME=TEST

[dbntsrv.gui]

[dbntsrv.dll]
comdll=sqlws32

[dbntsrv.ws32]
ListenPort=2156

[win32client]
clientname=Win32User

transports=tcp,npipe,apipe
clientruntimedir="C:\TD6.3\sqlbase"

[win32client.dll]
comdll=sqlws32

[win32client.ws32]
serverpath=SB63,127.0.0.1,2156/*

SB117:

[dbntsrv]
dbname=SBTASK
ANSIJoinSyntax=1
centurydefaultmode=1

NamedPipes=LocalOnly
servername=Sb117
dbdir=c:\sb117SP3
tempdir=c:\sb117SP3

DBNAME=STBLOBTEST
DBNAME=ISLAND
DBNAME=TEST

[dbntsrv.gui]

[dbntsrv.dll]
comdll=sqlws32

[dbntsrv.ws32]
ListenPort=2155

[win32client]
clientname=Win32User

transports=tcp,npipe,apipe
clientruntimedir=C:\sb117SP3

[win32client.dll]
comdll=sqlws32

[win32client.ws32]
serverpath=Sb117,localhost,2155/*

From the SQLTalk in the TD6.3 directory, I can connect to stblobtest on the SB117 server and at the same time connect to island on the TD6.3\sqlbase server. This uses the serverpath statements:

serverpath=SB63,127.0.0.1,2156/*
serverpath=sb117,127.0.0.1,2155/stblobtest

See the attachment. If I'm missing something...

Best regards,

[tfahey]

Hi Mike,
To answer your first question, yes we have two instances of SqlBase on the same server. I learned how to do that from one of the Gupta classes - long ago!
We simply start the 8.0 service first, then the 11.5 service secondly.

When I installed TD 6.3 I did not install the Sqlbase component. I wanted to avoid contamination of our complex environment. (For example, the Sqlbase 11.7 might be a different patch and so not really the correct version.) So I do not have a working Sqltalk on my local machine. However the 'Database Explorer' somewhat works. I do not know how or what it writes to, but it seems to read the same SQL.INI file as the TD Environment.

Further Note: We use SqlTalk all the time - but run it out of a directory on the network that has access to all servers. ( So in the sample shown below there would not be any commented out lines for Serverpath.

This is the entire SQL.INI file from the main TD Directory. With TD 6.3 - you can point to a different SQL.INI in the Preferences area. I have tried that but get the same results.
[win32client]
clientname=Win32User

[win32client.dll]
comdll=sqlws32

[win32client.ws32]
serverpath=serverx,10.0.85.15,3306/*
;serverpath=Serv2012,10.0.85.15,2155/acchall,accbutl,hbstate,hblew,hbral,hbmurf
;serverpath=serv117,10.0.85.30,2155/accral1,accwork,hbral1,hbwork,test1

[Mike Vandine]

Hi Tom,

Perhaps we can take this offline and get a solution, then post that here. Please email me on mike.vandine@guptatechnologies.com and we'll get this resolved.

Cheers!

[tfahey]

Thanks Mike,
I will contact you shortly.

Tom

[giscon]

Hi,
while trying out TD6.3 I also noticed these connection problems, but I found a workaround.
The behaviour was the same with TD6.3 itself (TD 6.3 Build 44741) and both SqlTalk's which can be installed together with TD6.3 (SqlTalk 10.0.0 in the install directory of Team Developer 6.3 itself and SqlTalk 11.7.3 10154 in the subdirectory sqlbase).

On the virtual Win7-machine I test with TD6.3 is no SqlBase-Server installed, all databases are on other servers.
In the sql.ini for TD6.3 I used the same client - section entries as in the sql.ini for installations of TD6.2 or TD6.1 and there was never any connection problem with it

Code: Select all

[win32client.ws32]
serverpath=Serv116,192.168.1.143,2155/*
serverpath=servtst,192.168.1.4,2157/imptest,profbg,demofbg
serverpath=msdo116,192.168.1.6,2155/foa113,foa117,foa226,foa498

But now with TD6.3 only connects to databases on the server with the wildcard entry are successful (in the example Serv116) , but any connect to a named databases on another server fails!
But without the wildcard entry (delete that line or just comment it out) the connect's to the named databases on the other servers worked!
So I tried also a change of the entry order, making the wildcard entry the last one:

Code: Select all

[win32client.ws32]
serverpath=servtst,192.168.1.4,2157/imptest,profbg,demofbg
serverpath=msdo116,192.168.1.6,2155/foa113,foa117,foa226,foa498
serverpath=Serv116,192.168.1.143,2155/*

Now all connect's were successful.

Best regards
Günter
Giscon Systems GmbH

[Mike Vandine]

Thanks for the follow-up!

I'm not sure if this is a changed behaviour. It would seem that the database searching stops if a wildcard entry is found and the database itself doesn't exist on that server. It should actually search *all* serverpath entries in the list.

I am going to log a defect for this!

Best regards,