Re: Consolidation
Grant McClure ( (no email) )
Fri, 30 May 1997 18:51:10 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_01BC6D2A.70B69840
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
David, I'd be interested in seeing your code. I was thinking of doing =
the same thing myself.
Dale, is there any reason that all the consolidation routines aren't =
just coded as SQL Server procedures? It'd be so much easier to edit =
them if that were the case. =20
I'm in the position where I don't like how the expiry date works in =
Emerald when it comes to doing consolidations and looking at the Time On =
for the calls.
When it comes to the consolidations, I always just want to consolidate =
the calls from the first of the last month to the last day of the last =
month. I don't care about the expiry date. The only way I can get =
around this now is to batch update expiry dates to the correct day =
before running consolidations.
I also noticed that if you do a consolidation more than once in a month =
that it tries to insert a 2nd row for a AccountID, Date Start and Months =
.... which has to be unique, so the insert fails and then the calls are =
deleted (lost). I sort of assumed it would do an update and add the =
calls and minutes to the prior amounts. I guess not. =20
The other thing that I find a little out is that the default time period =
to check for calls in the Time On tab is from the expiry date forward a =
month. But if my expiry date is set forward a month in order to =
consolidate my calls for last month ... I have to manually change the =
period every time I go into Time On ... which I sometimes forget to do =
.... and end up thinking ... Oh, this person has had no calls this =
month.
I realize that I'm not quite using the system the way that it was =
intended. But the product should be flexible enough to handle these =
different ways of handling things.
Thanks.
grant=20
----
From: Dale E. Reed Jr. <daler@iea.com>
To: emerald@emerald.iea.com
Date: May 30, 1997 2:38 AM
Subject: Re: Consolidation
David Khoury wrote:
>
> Yep ... glad I'm not the only one to have noticed the problem :) I
> thought our system was going crazy because some consolidation data was
> incorrect and yet there were no posts on the list about it.
Its one of those things that if you really don't look at it
closely, you won't see it.
> In any case, I'm currently writing my own consolidation routines now =
in
> Visual Basic. I'm practically done now. The only vexing question I =
have
> comes from the trace of the SQL calls during a test consolidation =
here.
> After every single "INSERT INTO Charges" statement, there is a =
following
> statement:
>
> "Select LastIdentity=3D@@IDENTITY"
>
> OK, so this selects the identity of the last row inserted into the =
charges
> table, but what is this used for?? I can't seem to find any reason =
for it.
> Am I overlooking something really simple??
>
> I'd appreciate any answer that anyone can provide.
You are right, this finds the indentify of the Charge. This is needed
so that
when the CallHistory entry is made, the ChargeID can be stored with it.
> I can mail anyone the code for my consolidation routine if they want =
it.
> Just mail me and I'll send it when it's ready (any day now :).
Gotta love an open solution like Emerald. Isn't reverse enginerring
illegal our something? I'd love to shoot the person that invented
SQL trace! Guess I will have to start using encrypted stored
procedures for this stuff. :)
The Emerald 2.2 consolidation code is corrected, and includes several
new
additions to handle large calls table (to try and prevent log full
errors,
etc. We can not gurantee accuracy or behavior in a setup where you are
externally manipulating mainstream events like this.
--Dale E. Reed Jr. (daler@iea.com)_________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQsInternet Solutions for Today | http://www.emerald.iea.com
----------------------------------------------------------Emerald Mailing List listserver@emerald.iea.com
------=_NextPart_000_01BC6D2A.70B69840Content-Type: text/html; charset="us-ascii"Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
David, I'd be interested in seeing your code. I was thinking of =doing the=20same thing myself.
Dale, is there any reason that all the consolidation routines aren't =just=20coded as SQL Server procedures? It'd be so much easier to edit them if =that=20were the case. =20
I'm in the position where I don't like how the expiry date works in =Emerald=20when it comes to doing consolidations and looking at the Time On for the =calls.
When it comes to the consolidations, I always just want to =consolidate the=20calls from the first of the last month to the last day of the last =month. I=20don't care about the expiry date. The only way I can get around this now =is to=20batch update expiry dates to the correct day before running =consolidations.
I also noticed that if you do a consolidation more than once in a =month that=20it tries to insert a 2nd row for a AccountID, Date Start and Months ... =which=20has to be unique, so the insert fails and then the calls are deleted =(lost). I=20sort of assumed it would do an update and add the calls and minutes to =the prior=20amounts. I guess not. =20
The other thing that I find a little out is that the default time =period to=20check for calls in the Time On tab is from the expiry date forward a =month. But=20if my expiry date is set forward a month in order to consolidate my =calls for=20last month ... I have to manually change the period every time I go into =Time On=20.... which I sometimes forget to do ... and end up thinking ... Oh, this =person=20has had no calls this month.
I realize that I'm not quite using the system the way that it was =intended. =20But the product should be flexible enough to handle these different ways =of=20handling things.
Thanks.
grant
----
From: Dale E. Reed Jr. <daler@iea.com>
To: emerald@emerald.iea.com
Date: May 30, 1997 2:38 AM
Subject: Re: Consolidation
David Khoury wrote:
>
> Yep ... glad I'm not the only one to have noticed the =problem=20:) I
> thought our system was going crazy because some consolidation data =was
> incorrect and yet there were no posts on the list about it.
Its one of those things that if you really don't look at it
closely, you won't see it.
> In any case, I'm currently writing my own consolidation =routines now in
> Visual Basic. I'm practically done now. The only vexing =question I have
> comes from the trace of the SQL calls during a test consolidation =here.
> After every single "INSERT INTO Charges" statement, there =is a=20following
> statement:
>
> "Select LastIdentity=3D@@IDENTITY"
>
> OK, so this selects the identity of the last row =inserted into=20the charges
> table, but what is this used for?? I can't seem to find any =reason=20for it.
> Am I overlooking something really simple??
>
> I'd appreciate any answer that anyone can provide.
You are right, this finds the indentify of the Charge. This is =needed
so that
when the CallHistory entry is made, the ChargeID can be stored with =it.
> I can mail anyone the code for my consolidation routine =if they=20want it.
> Just mail me and I'll send it when it's ready (any day now :).
Gotta love an open solution like Emerald. Isn't reverse =enginerring
illegal our something? I'd love to shoot the person that =invented
SQL trace! Guess I will have to start using encrypted stored
procedures for this stuff. :)
The Emerald 2.2 consolidation code is corrected, and includes =several
new
additions to handle large calls table (to try and prevent log full
errors,
etc. We can not gurantee accuracy or behavior in a setup =where you=20are
externally manipulating mainstream events like this.
--
Dale E. Reed Jr. (daler@iea.com)
_________________________________________________________________
IEA Software,=20Inc. | RadiusNT, Emerald, and NT =FAQs
Internet Solutions for Today | http://www.emerald.iea.com
----------------------------------------------------------
Emerald Mailing=20List =listserver@emerald.iea.com=
------=_NextPart_000_01BC6D2A.70B69840--