[RADIATOR] SQL Server connection
Hi, my company Antamedia has taken a Radiator Evaluation version. We installed the Strawberry Perl (64-bit) 5.18.2.2-64bit and DBI 1.631 on Windows Server 2012. We tested, but only work with auth file. We have created SQL server database, and all tables from sql file, but we have problem with connection on sql server. On this link is our radis config file. www.antamedia.com/download/radius.cfg We have problem to setup with auth sql and check account from database. Please help us to solve the problem and correct the error in radius config, in order to be able to continue testing. Thanks in advance Antamedia ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] SQL Server connection
Hello - You should start with the example SQL configuration file in “goodies/sql.cfg”. On Windows you should use ODBC and DBD-ODBC. To say any more we will need to see a copy of the configuration file together with a trace 4 debug showing what is happening. regards Hugh On 9 Jun 2014, at 21:05, Vojislav Mihailovic v...@antamedia.com wrote: Hi, my company Antamedia has taken a Radiator Evaluation version. We installed the Strawberry Perl (64-bit) 5.18.2.2-64bit and DBI 1.631 on Windows Server 2012. We tested, but only work with auth file. We have created SQL server database, and all tables from sql file, but we have problem with connection on sql server. On this link is our radis config file. www.antamedia.com/download/radius.cfg We have problem to setup with auth sql and check account from database. Please help us to solve the problem and correct the error in radius config, in order to be able to continue testing. Thanks in advance Antamedia ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER, SIM, etc. Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: (RADIATOR) SQL Server Connection Handling
Mike McCauley wrote: Hi Dan, OK, here is a new version of SqlDb.pm that implements a new DisconnectAfterQuery flag. This will cause AuthBy SQL and other SQL users to disconnect after every SQL 'do' and after every 'getOneRow'. Let me know how you go. Cheers. Thanks for all your effort, Mike. The problem didn't go away, however. I am suspecting a FreeTDS problem now. Server just hangs. 'top' shows it's in 'sbwait' state. 'netstat' shows an open connection to the MS SQL machine. Paulo Souso's Radiator also hangs, by the way. They use MS SQL too. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) SQL Server Connection Handling
We use DBD::Sybase with FreeTDS to connect to MSSQL Server 2000 from FreeBSD, and it works great, have never had any trouble. What version of FreeTDS are you using? You can also do some debugging with FreeTDS to see if it is the one hanging. http://www.freetds.org/userguide/x1873.htm#AEN1877 Hope this helps, -Patrick -- Patrick Muldoon, Network/Software Engineer INOC, LLC [EMAIL PROTECTED] If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside. - Robert X. Cringely -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Melomedman Sent: Thursday, September 05, 2002 10:57 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) SQL Server Connection Handling Mike McCauley wrote: Hi Dan, OK, here is a new version of SqlDb.pm that implements a new DisconnectAfterQuery flag. This will cause AuthBy SQL and other SQL users to disconnect after every SQL 'do' and after every 'getOneRow'. Let me know how you go. Cheers. Thanks for all your effort, Mike. The problem didn't go away, however. I am suspecting a FreeTDS problem now. Server just hangs. 'top' shows it's in 'sbwait' state. 'netstat' shows an open connection to the MS SQL machine. Paulo Souso's Radiator also hangs, by the way. They use MS SQL too. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) SQL Server Connection Handling
Forgive my ignorance, I was under the impression that FreeTDS would only work with SQL server 7.0 because as of 2000 microsoft changed the protocol so drastically that is will no longer work with freetds (which was written for sybase, essentially). Sincerely, Leon Oosterwijk ISDN-NET Inc. (615) 221-4200 http://www.isdn.net -Original Message- From: Patrick Muldoon(NOC) [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 05, 2002 10:40 AM To: 'Dan Melomedman' Cc: [EMAIL PROTECTED] Subject: RE: (RADIATOR) SQL Server Connection Handling We use DBD::Sybase with FreeTDS to connect to MSSQL Server 2000 from FreeBSD, and it works great, have never had any trouble. What version of FreeTDS are you using? You can also do some debugging with FreeTDS to see if it is the one hanging. http://www.freetds.org/userguide/x1873.htm#AEN1877 Hope this helps, -Patrick -- Patrick Muldoon, Network/Software Engineer INOC, LLC [EMAIL PROTECTED] If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside. - Robert X. Cringely -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Melomedman Sent: Thursday, September 05, 2002 10:57 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) SQL Server Connection Handling Mike McCauley wrote: Hi Dan, OK, here is a new version of SqlDb.pm that implements a new DisconnectAfterQuery flag. This will cause AuthBy SQL and other SQL users to disconnect after every SQL 'do' and after every 'getOneRow'. Let me know how you go. Cheers. Thanks for all your effort, Mike. The problem didn't go away, however. I am suspecting a FreeTDS problem now. Server just hangs. 'top' shows it's in 'sbwait' state. 'netstat' shows an open connection to the MS SQL machine. Paulo Souso's Radiator also hangs, by the way. They use MS SQL too. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Patrick Muldoon(NOC) wrote: We use DBD::Sybase with FreeTDS to connect to MSSQL Server 2000 from FreeBSD, and it works great, have never had any trouble. What version of FreeTDS are you using? You can also do some debugging with FreeTDS to see if it is the one hanging. http://www.freetds.org/userguide/x1873.htm#AEN1877 Hope this helps, -Patrick I am happy for you. We are using MSSQL 7.0, with service pack 2. We also use FreeTDS with PHP, and had some minor problems, but nothing major. There are/were many really screwy problems with FreeTDS like memory leaks and segfaults, and part of the problem is the reverse engineering, but it's a good suspect. We're always using the latest version of FreeTDS, and AFAIK it's been 0.53 for quite a while. This server hang problem is very irritating, and ambiguity of it really sucks. Where to look? DBD:Sybase? FreeTDS? MSSQL? So many layers. Does anyone on this list use MSSQL with Sybase client libraries by any chance? UnixODBC or iODBC with a commercial ODBC driver? What are your results? I've used Sybase client libraries with MSSQL 6.5 in the past with good results. Had more problems with 7.0. BTW, FreeTDS have a very early version of an ODBC driver. They're willing to finish it if you sponsor them. If FreeTDS makes you a profit, may as well support the developers :) === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Mike McCauley wrote:
On Wed, 28 Aug 2002 08:32, Hugh Irvine wrote:
Hello Dan -
I would have to suggest that you use a more sensible database.
Of course that there might be other reasons that prevent you from doing that.
I am a bit puzzled though: I would normally expect Radiator to attempt to
reconnect and have another go after failing to execute that query the first
time?
Perhaps if you send more the the trace file we might see if that is happening?
Cheers.
Here's what happens:
1) If the server has been writing to MSSQL server frequently, no problems.
2) If the server has not written anything over TCP connection to MSSQL
in quite a long while, the server is blocked. Any subsequent
requests to the server fail. This is the last thing in the log before a
block:
Wed Aug 28 18:58:52 2002 707093: DEBUG: do query is: insert into
failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-28
18:58:52.000','dan','203.63.154.1','987654321','1234','''Bad
Password''', 'prodnetilla') .
I suspect a problem may be with FreeTDS libraries, DBD::Sybase, or MSSQL
server itself. Unfortunately I can't use a different database for
logging for beauraucratical reasons.
A connect-log-disconnect feature would be a quick fix for this. It would
also allow some people simple load balancing with round-robin DNS to
boot.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hi Dan,
OK,
here is a new version of SqlDb.pm that implements a new DisconnectAfterQuery
flag. This will cause AuthBy SQL and other SQL users to disconnect after
every SQL 'do' and after every 'getOneRow'.
Let me know how you go.
Cheers.
On Fri, 30 Aug 2002 05:11, Dan Melomedman wrote:
Mike McCauley wrote:
On Wed, 28 Aug 2002 08:32, Hugh Irvine wrote:
Hello Dan -
I would have to suggest that you use a more sensible database.
Of course that there might be other reasons that prevent you from doing
that.
I am a bit puzzled though: I would normally expect Radiator to attempt to
reconnect and have another go after failing to execute that query the
first time?
Perhaps if you send more the the trace file we might see if that is
happening?
Cheers.
Here's what happens:
1) If the server has been writing to MSSQL server frequently, no problems.
2) If the server has not written anything over TCP connection to MSSQL
in quite a long while, the server is blocked. Any subsequent
requests to the server fail. This is the last thing in the log before a
block:
Wed Aug 28 18:58:52 2002 707093: DEBUG: do query is: insert into
failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-28
18:58:52.000','dan','203.63.154.1','987654321','1234','''Bad
Password''', 'prodnetilla') .
I suspect a problem may be with FreeTDS libraries, DBD::Sybase, or MSSQL
server itself. Unfortunately I can't use a different database for
logging for beauraucratical reasons.
A connect-log-disconnect feature would be a quick fix for this. It would
also allow some people simple load balancing with round-robin DNS to
boot.
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc
# SqlDb.pm
#
# Object for handling an SQL database.
# Routines are provided to connect to a server (and fall back
# to alternates if not available.
# Also routines to do generic prepare/execute
#
# This module also implements database handle sharing: all instances
# that connect to the same database with the same username and password
# will share the same database connection
#
# Author: Mike McCauley ([EMAIL PROTECTED])
# Copyright (C) 1997 Open System Consultants
# $Id: SqlDb.pm,v 1.19 2002/05/23 02:02:44 mikem Exp mikem $
package Radius::SqlDb;
@ISA = qw(Radius::Configurable);
use Radius::Configurable;
use DBI;
use strict;
%Radius::SqlDb::ConfigKeywords =
('DBSource' = 'stringarray',
'DBUsername' = 'stringarray',
'DBAuth' = 'stringarray',
'Timeout'= 'integer',
'FailureBackoffTime' = 'integer',
'DateFormat' = 'string',
'DisconnectAfterQuery' = 'flag',
);
# This is a has of $dbsource;$dbusername;$dbauth to database handle
# that allows multuple instances to share handles
%Radius::SqlDb::handles;
#
# Constructs a new SQL database
sub new
{
my ($class, @args) = @_;
my $self = $class-SUPER::new(@args);
$self-log($main::LOG_WARNING,
No DBSource defined for $class at '$main::config_file' line $.)
if @{$self-{DBSource}} == 0;
return $self;
}
#
# Do per-instance default initialization
# This is called by Configurable during Configurable::new before
# the config file is parsed. Its a good place initalze
# instance variables
# that might get overridden when the config file is parsed.
sub initialize
{
my ($self) = @_;
$self-SUPER::initialize;
# Empty arrays for database details
$self-{DBSource} = [];
$self-{DBUsername} = [];
$self-{DBAuth} = [];
$self-{Timeout}= 60; # Seconds
$self-{FailureBackoffTime} = 600; # Seconds
$self-{DateFormat} = '%b %e, %Y %H:%M'; # eg 'Sep 3, 1995 13:37'
}
#
# reconnect
# Connect or reconnect to a database
# Returns true if there is a viable database connection available
sub reconnect
{
my ($self) = @_;
# Implement backoff strategy in case of database failure
return 0 if time $self-{backoff_until};
if (!$Radius::SqlDb::handles{$self-{dbname}})
{
print Reconnecting to $self-{dbname}\n;
# A new connection is required, try all the
# ones in the $self-{DBSource} in order til we
# find either an existing shared one, or a can create
# a new connection
my $i;
for ($i =
Re: (RADIATOR) SQL Server Connection Handling
Mike McCauley wrote:
Its a first for me too.
I could conceive of a 'DisconnectAfterQuery' flag that would disconnect after
every SQL query was finished, but Im reluctant to add it since I dont think
it would be widely useful, and when it was used it would significantly slow
things down.
Performance is not an issue for us right now, since we barely get a few
dozen authentications per day.
Do I understand from the below that you are connecting to MS-SQL from Radiator
running on a FreeBSD box?
We havent heard of similar behaviour, even from FreeBSD to MS-SQL. It is
possible that using keep-alives or similar might alleviate the problem?
Cheers.
The problem is our MS SQL Server 7.0 (yuck!), service pack 2 drops connections if
they're idle for a long enough time:
Tue Aug 13 09:39:24 2002: ERR: do failed for 'insert into failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-13 09:39:24.000','soconnell','10.0.2.201','',
'29374','''Bad Password''','prodnetilla')': Server message number=10018 severity=9
state=0 line=0
server=OpenClient text=The connection was closed
I am just looking for a a quick work-around. MS' site actually has a blurb about
configuring time-outs
for DB connections, but we couldn't find such an option at least for our
service pack.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hello Dan -
I would have to suggest that you use a more sensible database.
This mail is copied to Mike for his comments.
regards
Hugh
On Wednesday, August 28, 2002, at 01:13 AM, Dan Melomedman wrote:
Mike McCauley wrote:
Its a first for me too.
I could conceive of a 'DisconnectAfterQuery' flag that would
disconnect after
every SQL query was finished, but Im reluctant to add it since I dont
think
it would be widely useful, and when it was used it would significantly
slow
things down.
Performance is not an issue for us right now, since we barely get a few
dozen authentications per day.
Do I understand from the below that you are connecting to MS-SQL from
Radiator
running on a FreeBSD box?
We havent heard of similar behaviour, even from FreeBSD to MS-SQL. It
is
possible that using keep-alives or similar might alleviate the problem?
Cheers.
The problem is our MS SQL Server 7.0 (yuck!), service pack 2 drops
connections if
they're idle for a long enough time:
Tue Aug 13 09:39:24 2002: ERR: do failed for 'insert into failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-13
09:39:24.000','soconnell','10.0.2.201','',
'29374','''Bad Password''','prodnetilla')': Server message number=10018
severity=9 state=0 line=0
server=OpenClient text=The connection was closed
I am just looking for a a quick work-around. MS' site actually has a
blurb about configuring time-outs
for DB connections, but we couldn't find such an option at least for our
service pack.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
On Wed, 28 Aug 2002 08:32, Hugh Irvine wrote:
Hello Dan -
I would have to suggest that you use a more sensible database.
Of course that there might be other reasons that prevent you from doing that.
I am a bit puzzled though: I would normally expect Radiator to attempt to
reconnect and have another go after failing to execute that query the first
time?
Perhaps if you send more the the trace file we might see if that is happening?
Cheers.
This mail is copied to Mike for his comments.
regards
Hugh
On Wednesday, August 28, 2002, at 01:13 AM, Dan Melomedman wrote:
Mike McCauley wrote:
Its a first for me too.
I could conceive of a 'DisconnectAfterQuery' flag that would
disconnect after
every SQL query was finished, but Im reluctant to add it since I dont
think
it would be widely useful, and when it was used it would significantly
slow
things down.
Performance is not an issue for us right now, since we barely get a few
dozen authentications per day.
Do I understand from the below that you are connecting to MS-SQL from
Radiator
running on a FreeBSD box?
We havent heard of similar behaviour, even from FreeBSD to MS-SQL. It
is
possible that using keep-alives or similar might alleviate the problem?
Cheers.
The problem is our MS SQL Server 7.0 (yuck!), service pack 2 drops
connections if
they're idle for a long enough time:
Tue Aug 13 09:39:24 2002: ERR: do failed for 'insert into failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-13
09:39:24.000','soconnell','10.0.2.201','',
'29374','''Bad Password''','prodnetilla')': Server message number=10018
severity=9 state=0 line=0
server=OpenClient text=The connection was closed
I am just looking for a a quick work-around. MS' site actually has a
blurb about configuring time-outs
for DB connections, but we couldn't find such an option at least for our
service pack.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) SQL Server Connection Handling
Hi. Is it possible to quickly disable persistent connections for SQL logging? Persistent connections do not work well with our SQL Server, since they time out. Short failure backoff times do not help either since I think any DB connection failure trips the RADIUS authentication code on the devices we authenticate (they stop talking to Radiator). === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hello Dan - Can you please tell me what database you are using and what platform? thanks Hugh On Tuesday, August 27, 2002, at 04:34 AM, Dan Melomedman wrote: Hi. Is it possible to quickly disable persistent connections for SQL logging? Persistent connections do not work well with our SQL Server, since they time out. Short failure backoff times do not help either since I think any DB connection failure trips the RADIUS authentication code on the devices we authenticate (they stop talking to Radiator). === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hugh Irvine wrote: Hello Dan - Can you please tell me what database you are using and what platform? thanks Hugh I thought SQL Server implied MS SQL Server :). This is FreeBSD. Anyway, we need connect-log-disconnect behavior instead of the current implementation. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hello Dan - I must confess that this is the first time I have ever heard this request. All other previous requests in this area have been for long-held connections to the SQL server. I have copied this mail to Mike for further comments. regards Hugh On Tuesday, August 27, 2002, at 12:31 PM, Dan Melomedman wrote: Hugh Irvine wrote: Hello Dan - Can you please tell me what database you are using and what platform? thanks Hugh I thought SQL Server implied MS SQL Server :). This is FreeBSD. Anyway, we need connect-log-disconnect behavior instead of the current implementation. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hello Dan, On Tue, 27 Aug 2002 14:49, Hugh Irvine wrote: Hello Dan - I must confess that this is the first time I have ever heard this request. All other previous requests in this area have been for long-held connections to the SQL server. I have copied this mail to Mike for further comments. Its a first for me too. I could conceive of a 'DisconnectAfterQuery' flag that would disconnect after every SQL query was finished, but Im reluctant to add it since I dont think it would be widely useful, and when it was used it would significantly slow things down. Do I understand from the below that you are connecting to MS-SQL from Radiator running on a FreeBSD box? We havent heard of similar behaviour, even from FreeBSD to MS-SQL. It is possible that using keep-alives or similar might alleviate the problem? Cheers. regards Hugh On Tuesday, August 27, 2002, at 12:31 PM, Dan Melomedman wrote: Hugh Irvine wrote: Hello Dan - Can you please tell me what database you are using and what platform? thanks Hugh I thought SQL Server implied MS SQL Server :). This is FreeBSD. Anyway, we need connect-log-disconnect behavior instead of the current implementation. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
