Re: Expiration Dates

Dale E. Reed Jr. ( (no email) )
Tue, 17 Feb 1998 02:04:45 -0800

Mitch Wagers wrote:
> It seems we are having a problem using expiration dates...
> RadiusNT v2.2 Secondary AND 1.16.49 Primary
> NT 4.0 - ODBC 3.5
> Accounts that have an expiration date don't actually expire, regardless of
> their Extension. This works on 1.16.49 (I do believe, I've done it), but not
> on 2.2. I viewed the SQL SELECT statement from an auth. request and found it
> doesn't even select the Expiration Dates/Extension from the SubAccounts
> table, only the MasterAccounts table, it even selects it twice...identically
> in the same statement. My first question is why does 1.16.49 do this
> correctly while 2.2 ignores the SubAccounts table for the fields? Also, we
> aren't running SQL Server as of yet and it would be very beneficial to have
> this option seeing that that is what the Extension/saExpireDate is supposed
> to do!

MS Access errors when DateAdd() encounters a NULL (saExtension). This
became an issue with 2.2, because we let the RDBMS do the math, rather
than do it all in RadiusNT. Therefore, 2.2 and higher doesn't support
the saExpireDate/saExtension. Those two fields never should be used,
anyways. If you are using them, you are probably using them in a way
they were not intended to be used.

SQL Server handles this correctly and therefore, saExpireDate/Extension
is supported with SQL Server.

> While running the debug, I also noticed in the SELECT statement the use of
> DateAdd. I hope I'm assuming correctly there is code to handle an expiration
> date of 1/25/97 and Extension of 10, so the final result from DateAdd is 2/4/97?

DateAdd() is an RDBMS function. All of them handle month/year rollovers
just fine.

> I need to get this fixed soon!

There is nothing broken.

-- Dale E. Reed Jr.  (       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |