ersonally, I would stick with the API.
First, the speed increase is not that important when you consider the
volume of the information that you are returning in your result set. The
goal is not to process tens of thousands, or even millions of rows, but
rather to get the previous days data. (If you need the additional speed,
don't the query function. Returning a result set is always slower than
simply returning the ticket. Use a counter and cycle through.)
Second, using the ARSPerl module gives you access to metadata about the
form (screama?) and fields. The field length, type, etc. can all be
derived from the module. Trying to accomplish this via a sql connection
to the database is a pain.
Next, it should be noted that using the API allows records which you
might be modifying or creating to pass through the filter layer so that
whatever workflow your administrator might have built will operate on
them. Unless you happen to be quite handy with the stored procedures,
and triggers on your particular database platform, you're going to be
hard pressed to duplicate this.
Why would you want to use the DBI when the getlistsql function is
available? Write your statement, and it is passed off to the database
server via the ARAPI for execution. Simple and it works.
Remember that the views that you are using are only there as a courtesy.
They don't have to be there at all. I have seen installations where some
of them are gone, and the AR System works just fine.
One more item.... I am going from memory here, so you might have to look
this one up... I cannot remember off the top of my head whether or not
the ARSPerl module obeys the concept of hidden fields, or fields to
which the use that is authenticated via the script has access to. I am
leaning toward the position that it does, meaning that your script might
not be able to "see" a particular field if there is no permission to it.
Now, this works out to an advantage if you have fields that you don't
want seen,
Finally, consider that - by using the DBI - you're communicating
directly with the database, and are effectively BYPASSING all of the
protection mechanisms which the application has in place. Which ones?
How about the administrative limitation placed on the system for a
maximum number of rows returned in a query?
So what happens if you kick this script off at the same time that your
end users are in there? It would be hard to explain why "the system" was
unavailable because a poorly qualified statement in an external script
decided to cycle through the contents of a table. I've watched that
happen to developers in the past, and still find it humorous when they
try to explain that....
Use the right tool for the right job.
Just my thoughts - offered humbly....
Andrew Hicox wrote:
all in all, it'll be MUCH easier to use the database backend for
queries in perl.
The ARS API is pretty good but it's slow for queries compared to using
the SQL backend.
-A
On May 28, 2007, at 12:26 PM, Ray M wrote:
**
Hi: I want to grab all the closed tickets for a particular day and
last 5 worklogs for the ticket every evening. I know I can use perl
DBI to access the view (hpd_help_desk), grab the closed tickets and
go to the view for the worklog and grab the worklogs. Wondering if
doing the same thing is easier via ARS perl? Could someone who has
used ARSPerl provide reasons why it might be a good idea to use ARS
Perl or is it ok either way?
Thanks
Ray
__20060125_______________________This posting was submitted with
HTML in it___
Andrew N. Hicox
Hicox Information Systems LLC
Manassas, VA USA
http://hicox.com
[EMAIL PROTECTED]
703-367-9085
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
ARSlist:"Where the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
