El 28 Jul 2001, a las 19:36, Hugh Irvine escribi�:
>
> Hello Mariano -
>
> You can do what you describe too, by using the AccountingStartsOnly,
> AccountingStopsOnly and AccountingAlivesOnly tags in the AuthBy SQL
> clause.
That was (and still is) my intention... the only thing that worried my was the
following paragraph from section 6.26 of the 2.18.2 release manual (see underlines
under a fixed text viewer):
> When AuthBy SQL receives an Accounting-Request message, it can store any
> number of the attributes from the request in an SQL table. You can control
> the table it stores in, and the names of the columns where the attributes
> are stored, and the attribute that is stored there. To enable SQL
^^^^^^^^^^^^^
> accounting you must define AccountingTable and you must define at least
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> one AcctColumnDef. If you don't do both of these AuthBy SQL will
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> acknowledge Accounting-Request message but will not store them anywhere.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The example goodies/sql.cfg in the Radiator distribution shows a typical
> setup that will work with the table schemas in the goodies directory.
Re-reading this, this is, in fact true since, in this specific <AuthBy>, I am not
storing them anywhere, but I am doing something else besides aknowledging them.
>
> Have a look at section 6.26 in the Radiator manual.
>From doing this I got the original doubt :-)
>
> regards
Thanx for your help...
>
> Hugh
>
>
> At 15:22 -0300 01/7/27, Mariano Absatz wrote:
> >El 27 Jul 2001, a las 9:17, Hugh Irvine escribi�:
> >
> >>
> >> Hello Mariano -
> >>
> >> Yes you can certainly have any number of AcctSQLStatement's without an
> >> AccountingTable and AcctColumnDef's.
> >>
> >> You might want to think about using Handlers to process your requests.
> >>
> >> Something like this:
> >>
> >> # define Handler to process accounting stops
> >>
> >> <Handler Acct-Status-Type = Stop>
> >> .....
> >> </Handler>
> >>
> >> # define Handler to process other accounting requests
> >>
> >> <Handler Request-Type = Accounting-Request>
> >> .....
> >> </Handler>
> >Yes...
> >but nonetheless, I want to apply all of the processing of <Handler Request-
> >Type = Accounting-Request> to the same packets that also match <Handler Acct-
> >Status-Type = Stop> and it is "cleaner" (at least for my eye) if I have one
> ><AuthBy OnlyDoThisWithStops> and one <AuthBy DoThisWithEveryAcctPack> and use
> >both in the <Handler Request-Type = Accounting-Request>.
> >
> >>
> >> # define Handlers for everything else
> >>
> >> <Handler .....>
> >> .....
> >> </Handler>
> >>
> >> <Handler>
> >> .....
> >> </Handler>
> >>
> >> hth
> >>
> >> Hugh
> >>
> >>
> >> On Friday 27 July 2001 03:20, Mariano Absatz wrote:
> >> > Hi,
> >> >
> >> > is it possible to have an <AuthBy SQL> that doesn't even have
> >> > AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual
> >> > seems to say "no".
> >> >
> >> > Here's what I want to do:
> >> >
> >> > I already have my "main" accounting only <AuthBy SQL> that processes
> >> > Start's Stop's and, if they are there, Alive's.
> >> >
> >> > Now I want to do a couple of AcctSQLStatement's but I want them only to
> >> > be executed when I get a Stop packet (to do time-block and also
> >> > "byte"-block)
> >> >
> >> > I want to use AccountingStopsOnly in my new <AuthBy SQL> especially
> >> > trying to avoid Alive packets that would make accumulative substract
> >> > time when I shouldn't.
> >> >
> >> > I don't want to ignore altogether alive packets because billing will use
> >> > them if the Stop packet gets lost...
> >> >
> >> > Any ideas?
> >> >
--
Mariano Absatz
El Baby
----------------------------------------------------------
Not the brightest crayon in the box now, are we?
===
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.
