Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

6420 when connecting to data via ODBC on a different server

3 posts in ODBC Last posting was on 2010-07-14 13:35:32.0Z
Lynne Maher Posted on 2010-07-13 20:01:15.0Z
From: "Lynne Maher" <lmaher@paradox.com>
Newsgroups: advantage.odbc
Subject: 6420 when connecting to data via ODBC on a different server
Date: Tue, 13 Jul 2010 16:01:15 -0400
Lines: 29
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: 206.41.90.173
Message-ID: <4c3cc5af@solutions.advantagedatabase.com>
X-Trace: 13 Jul 2010 13:59:43 -0700, 206.41.90.173
Path: solutions.advantagedatabase.com!206.41.90.173
Xref: solutions.advantagedatabase.com Advantage.ODBC:1891
Article PK: 1133266

Hi all,

Here is the situation:

We have 2 servers: A and B and an application that runs as a windows
service. ADS runs on A and data also resides on A. When the service on A
accesses data via ODBC on A... no problem.

But sometimes when the service on server B accesses data on A via ODBC and
we have a network failure of some sort, we get a 6420. Any attempts at
connecting to data from this point on is useless until we stop/start our
service.

Today, the same situation happened but with IIS instead of our own service.
This has brought us to think that the ODBC dll does not release what it
needs to when a connection is not successful. So any attempt at creating a
connection after the initial 6420 remains unsuccessful.

So far, we have checked the ODBC version versus ADS version which are the
same. We have also tried connecting with \\A:6262\sharename\MyDict.add in
the ODBC configuration without any success. And I can recreate this problem
at will.

Thank you all for any help you might give us

Lynne Maher
Paradox Security Systems Ltd


Edgar Sherman Posted on 2010-07-13 21:16:08.0Z
Date: Tue, 13 Jul 2010 15:16:08 -0600
From: Edgar Sherman <no@email.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
Newsgroups: advantage.odbc
Subject: Re: 6420 when connecting to data via ODBC on a different server
References: <4c3cc5af@solutions.advantagedatabase.com>
In-Reply-To: <4c3cc5af@solutions.advantagedatabase.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: 10.24.34.181
Message-ID: <4c3cd6ea@solutions.advantagedatabase.com>
X-Trace: 13 Jul 2010 15:13:14 -0700, 10.24.34.181
Lines: 72
Path: solutions.advantagedatabase.com!10.24.34.181
Xref: solutions.advantagedatabase.com Advantage.ODBC:1892
Article PK: 1133268

Try setting retry_ads_connects=1 to your ads.ini file (note you may need
to create one)

here is the help file
http://devzone.advantagedatabase.com/dz/WebHelp/Advantage10/master_ads_ini_file_support.htm?zoom_highlightsub=retry_ads_connects

==================
RETRY_ADS_CONNECTS
This setting controls the functionality associated with the Advantage
Database Server connection errors being cached. The RETRY_ADS_CONNECTS
setting must exist within a section titled "[SETTINGS]". By default, the
Advantage Client Engine caches certain errors that are generated during
attempts to connect to the Advantage Database Server. This allows future
connection attempts to avoid some of the timeout periods associated with
the Advantage Database Server discovery process. For example, if a
connection to the Advantage Database Server fails, all future connection
attempts to that server from a particular client will immediately return
the same error code.
It can take several seconds for the client to determine that the
Advantage Database Server is not available on a specified server. By
saving the server name and error code related with a failed connection
attempt to an Advantage Database Server, the application only has to
attempt to connect one time. All future "ADS_REMOTE" connection attempts
will fail immediately rather than possibly waiting several seconds each.
This is particularly useful if you distribute an application that scales
to the Advantage Local Server if the Advantage Database Server is not
available.
By setting the value to 1, every "ADS_REMOTE" connection attempt to a
server will look for the Advantage Database Server regardless of the
success of past connection attempts. If you want your application to
check for the Advantage Database Server each time it attempts an
"ADS_REMOTE" connection, you need to create an ads.ini file with the
following entry:
[SETTINGS]
RETRY_ADS_CONNECTS = 1
The default for this setting is 0.
Note RETRY_ADS_CONNECTS was designed such that modifying the ads.ini
file programmatically will change the connection behavior for the next
connection made.
=======================
Edgar

On 7/13/2010 2:01 PM, Lynne Maher wrote:
> Hi all,
>
> Here is the situation:
>
> We have 2 servers: A and B and an application that runs as a windows
> service. ADS runs on A and data also resides on A. When the service on A
> accesses data via ODBC on A... no problem.
>
> But sometimes when the service on server B accesses data on A via ODBC and
> we have a network failure of some sort, we get a 6420. Any attempts at
> connecting to data from this point on is useless until we stop/start our
> service.
>
> Today, the same situation happened but with IIS instead of our own service.
> This has brought us to think that the ODBC dll does not release what it
> needs to when a connection is not successful. So any attempt at creating a
> connection after the initial 6420 remains unsuccessful.
>
> So far, we have checked the ODBC version versus ADS version which are the
> same. We have also tried connecting with \\A:6262\sharename\MyDict.add in
> the ODBC configuration without any success. And I can recreate this problem
> at will.
>
> Thank you all for any help you might give us
>
> Lynne Maher
> Paradox Security Systems Ltd
>
>


Lynne Maher Posted on 2010-07-14 13:35:32.0Z
From: "Lynne Maher" <lmaher@paradox.com>
Newsgroups: advantage.odbc
References: <4c3cc5af@solutions.advantagedatabase.com> <4c3cd6ea@solutions.advantagedatabase.com>
Subject: Re: 6420 when connecting to data via ODBC on a different server
Date: Wed, 14 Jul 2010 09:35:32 -0400
Lines: 88
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5512
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
NNTP-Posting-Host: 206.41.90.173
Message-ID: <4c3dbcc7@solutions.advantagedatabase.com>
X-Trace: 14 Jul 2010 07:33:59 -0700, 206.41.90.173
Path: solutions.advantagedatabase.com!206.41.90.173
Xref: solutions.advantagedatabase.com Advantage.ODBC:1893
Article PK: 1133269

Hi Edgar,

Thank you very much for your help, it did the trick. We do have network
problems, we know that for sure, but it's not in our hands to deal with. At
least now the application is really retrying to connect.

Regards
Lynne

"Edgar Sherman" <no@email.com> wrote in message
news:4c3cd6ea@solutions.advantagedatabase.com...
> Try setting retry_ads_connects=1 to your ads.ini file (note you may need
> to create one)
>
> here is the help file
> http://devzone.advantagedatabase.com/dz/WebHelp/Advantage10/master_ads_ini_file_support.htm?zoom_highlightsub=retry_ads_connects
>
> ==================
> RETRY_ADS_CONNECTS
> This setting controls the functionality associated with the Advantage
> Database Server connection errors being cached. The RETRY_ADS_CONNECTS
> setting must exist within a section titled "[SETTINGS]". By default, the
> Advantage Client Engine caches certain errors that are generated during
> attempts to connect to the Advantage Database Server. This allows future
> connection attempts to avoid some of the timeout periods associated with
> the Advantage Database Server discovery process. For example, if a
> connection to the Advantage Database Server fails, all future connection
> attempts to that server from a particular client will immediately return
> the same error code.
> It can take several seconds for the client to determine that the Advantage
> Database Server is not available on a specified server. By saving the
> server name and error code related with a failed connection attempt to an
> Advantage Database Server, the application only has to attempt to connect
> one time. All future "ADS_REMOTE" connection attempts will fail
> immediately rather than possibly waiting several seconds each. This is
> particularly useful if you distribute an application that scales to the
> Advantage Local Server if the Advantage Database Server is not available.
> By setting the value to 1, every "ADS_REMOTE" connection attempt to a
> server will look for the Advantage Database Server regardless of the
> success of past connection attempts. If you want your application to check
> for the Advantage Database Server each time it attempts an "ADS_REMOTE"
> connection, you need to create an ads.ini file with the following entry:
> [SETTINGS]
> RETRY_ADS_CONNECTS = 1
> The default for this setting is 0.
> Note RETRY_ADS_CONNECTS was designed such that modifying the ads.ini file
> programmatically will change the connection behavior for the next
> connection made.
> =======================
> Edgar
>
> On 7/13/2010 2:01 PM, Lynne Maher wrote:
>> Hi all,
>>
>> Here is the situation:
>>
>> We have 2 servers: A and B and an application that runs as a windows
>> service. ADS runs on A and data also resides on A. When the service on A
>> accesses data via ODBC on A... no problem.
>>
>> But sometimes when the service on server B accesses data on A via ODBC
>> and
>> we have a network failure of some sort, we get a 6420. Any attempts at
>> connecting to data from this point on is useless until we stop/start our
>> service.
>>
>> Today, the same situation happened but with IIS instead of our own
>> service.
>> This has brought us to think that the ODBC dll does not release what it
>> needs to when a connection is not successful. So any attempt at creating
>> a
>> connection after the initial 6420 remains unsuccessful.
>>
>> So far, we have checked the ODBC version versus ADS version which are the
>> same. We have also tried connecting with \\A:6262\sharename\MyDict.add in
>> the ODBC configuration without any success. And I can recreate this
>> problem
>> at will.
>>
>> Thank you all for any help you might give us
>>
>> Lynne Maher
>> Paradox Security Systems Ltd
>>
>>