Folks,
I'm trying to get a read from you on whether an issue we have discovered with
logging is worth submitting to spectrasource.macromedia.com. I would
appreciate any guidance you may have on the matter.
First I'll start with three no-brainers we ARE hoping to submit.
1. Unless we add a trailing slash to the logfile path in the webtop, the files
are written to "log\cfasomething" in /var/allaire/spectra/logs. Sadly, the
BROWSE jiffy does not add the trailing slash.
2. Next problem - logprocessor.cfm contains a few Windows/NT filename path
descriptors which use "\" instead of "/" to setup the directory structure.
Again, logfile processing dies horribly.
3. Once we got past these two we hit the next fatal error - logfile processing
will die if it encounters a zero-length logfile. ColdFusion catches an Solaris
"Err#22 EINVAL" and dumps this to the user, aborting logfile processing.
Here's the truss output from the ColdFusion server:
open("/opt/allaire/spectra/logs//cfa.3707622.spectralog.working", O_RDONLY) =
25
mmap(0x00000000, 0, PROT_READ, MAP_PRIVATE, 25, 0) Err#22 EINVAL
close(25) = 0
We have fixes for 2 & 3, but aren't quite certain how to handle 1. For us it
may boil down to a training issue. We'll just make sure to enter the trailing
slash into the jiffy.
I wonder - is 3. a ColdFusion-5.0 server bug? If so, to whom should I report?
Our workaround is simply to ignore the error and move on . . . not
particularly elegant.
So anyway, those are the ones we have a handle on. The one I really need your
feedback on is one which has us a bit more confounded. We're trying to get
"most popular path" reports and that's failing miserably, for reasons we think
we understand. The problem is, it looks to us like it never would have worked
with ORACLE as the DB, so we're looking for a sanity check.
Recognizing that these paths would be comprised of a bunch of UUIDs all
concatenated together, someone decided that the paths should be stored as
CLOBS in ORACLE, which allows much larger storage capacity than VARCHAR2.
/opt/allaire/spectra/customtags/system/coapi/datamigration/_oraclegeneraterepor
ttables.cfm uses the following schema for the pathreports table:
�
<cfquery name="createpathreports" datasource="#dataSource#">
������� CREATE TABLE� pathreports� (
��������������� day number (18, 0) NULL ,
��������������� weekofyear number (18, 0) NULL ,
��������������� month number(18, 0) NULL ,
��������������� year number (18, 0) NULL ,
��������������� hitcounter number (18, 0) NULL ,
��������������� siteid char (35) NULL ,
��������������� sectionid char (35) NULL ,
��������������� path clob NULL
������� )
</cfquery>
The problem is, the 'Popular Paths' report tries to do something that can't be
done with CLOBS. When you run the report template called 'Popular Paths' which
takes the log files and inserts them into the db you get this error (we have
tried this using the native and odbc drivers):
Oracle Error Code = 932
ORA-00932: inconsistent datatypes
SQL = "select * from pathreports where day = 37090 and path =
'78E17C62-F885-11D4-A2E400508BD39308,78E17C62-F885-11D4-A2E400508BD39308'"
Data Source = "REPORTING"
Our DBA assures me you cannot do "where path = 'string'" when the datatype is
a CLOB, which makes me wonder how anyone ever got this to work!???
Our workaround is going to be to change the "path" column to be VARCHAR2, and
make sure we truncate the data we're inserting to 4000 characters. That means
we're going to only see paths to a certain depth, but we can't really see an
alternative at this point.
WHAT ARE WE MISSING?
Thanks, any feedback would be most welcome - we'd love to get some of these
fixed to the point where we can upload them to spectrasource, but I'm not sure
we're going to make it without some guidance.
-Darren
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/spectra_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
