-Original Message-
From: Les Mizzell
To: CF-Talk
Sent: Thu Feb 22 03:39:16 2007
Subject: Re: Change Log on database updates - need some ideas
Dave Watts wrote:
I'm pretty much dealing with a single table. It's roughly
800 records with around 1200 columns.
if you don't mind me saying
LOL. Yeah, sorry-- I see idea and I'm off. ;-)
I forgot there was a real application we were contemplating, vs.
just philosophy of how to achieve X.
For thread justice:
The way I've handled it, in a similar case, was with a duplicate table.
Assuming you've got your DB code abstracted to a
Assuming you've got your DB code abstracted to a central place
(to totally misuse abstract, probably), it should be a snap to add
a secondary insert into the duplicate table whenever an update
occurs.
Then add a function that loops through those records, and creates
a diff for the modified
Most JS libs worth their salt have in-line editing type deals
(where you're in a view and you click on a field, say the
First Name field, and it becomes a text-box so that you can
edit content)- aside from the first insert, how often is
/every/ field changed? That's the beauty of AJAX,
Dave Watts wrote:
I shouldn't complain too much, as they don't care how
much it costs and pay quickly - but, is there a more
efficient way of doing this?
triggers.
AJAX. Field-based editing with a simple log. =]
I'm sorry, but that, by itself, is a very silly answer.
AJAX
Dave Watts wrote:
I shouldn't complain too much, as they don't care how
much it costs and pay quickly - but, is there a more
efficient way of doing this?
triggers.
AJAX. Field-based editing with a simple log. =]
I'm sorry, but that, by itself, is a very silly answer.
AJAX
On 2/21/07, Dave Watts @figleaf.com wrote:
AJAX is FAR from a display technology*. Far far far.
But I do love my fancy fades and whatnot. :-)
AJAX is not far from a display technology. That's all it is. It lets you
reorder your presentation logic in a way different from
I feel it's ridiculous to track changes to fields BEFORE the
complete data
set (form) is submitted, unless that is a specific intention of the business
logic, which I don't think in this case it is.
Basically, ADMIN sends an email to all the sys managers that have
systems listed in the
On 2/21/07, Andy Tyrone [EMAIL PROTECTED] wrote:
I feel it's ridiculous to track changes to fields BEFORE the complete data
set (form) is submitted, unless that is a specific intention of the
business
logic, which I don't think in this case it is. Just because AJAX can do
all
that
Well, actually, once you go AJAX, you kinda want it
everywhere. It truly
is a different way of doing stuff than the old static way.
What's that
quote... we're just now getting back to where we were 10 years ago, UI
wise something like that.
Well, I really disagree with that
Well, actually, once you go AJAX, you kinda want it
everywhere. It truly
is a different way of doing stuff than the old static way.
What's that
quote... we're just now getting back to where we were 10 years ago, UI
wise something like that.
Well, I really disagree with that
Just so my previous email doesn't get drowned out in a debate over ajax,
if I were tackling this problem, I would have a hidden form field on
each page that lists the fields that have been changed. Attach an
onChange handler to each form field that the sys managers can change.
Have it call a
All AJAX is is JavaScript. It's not really something different.
XHTMLHTTPRequest stuff could have been done with frames/whatnot.
Or was done, I guess I'd stipulate.
You're missing my point, which is that AJAX is not, by itself, a relevant
answer to the question, how do I log database changes?
I have programmed comprehensive audit trails and data change logs a
few times before. I recommend using triggers on every database table
that needs to be tracked, and force all queries to go through stored
procedures. The benefit of using triggers is that if you go directly
to the database and
On 2/21/07, Mike Chabot wrote:
I have programmed comprehensive audit trails and data change logs a
few times before. I recommend using triggers on every database table
that needs to be tracked, and force all queries to go through stored
procedures. The benefit of using triggers is that if you
Oh, one third issue, you'll have to have a trigger for each table.
I'm pretty much dealing with a single table. It's roughly 800 records
with around 1200 columns.
The table is already populated with basic info on all the systems in
question. There's is usually only one person involved with
C. Hatton Humphrey wrote:
Second is the fact that while you can look at the tables, extracting
the field names can be a different issue. For this I actually used a
lookup table that held the table name and column names of the columns
I wanted to log.
for insert delete i would imagine that's
Les Mizzell wrote:
I'm pretty much dealing with a single table. It's roughly 800 records
with around 1200 columns.
if you don't mind me saying, there's something wrong here.
~|
ColdFusion MX7 and Flex 2
Build sales
I'm pretty much dealing with a single table. It's roughly
800 records with around 1200 columns.
if you don't mind me saying, there's something wrong here.
Maybe they're all bit datatypes.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Software provides the highest
Dave Watts wrote:
I'm pretty much dealing with a single table. It's roughly
800 records with around 1200 columns.
if you don't mind me saying, there's something wrong here.
Maybe they're all bit datatypes.
even if they came w/ice cream, 1200 columns is too many, smells like
Dave Watts wrote:
I'm pretty much dealing with a single table. It's roughly
800 records with around 1200 columns.
if you don't mind me saying, there's something wrong here.
Their database, not mine. It's a big flat thing.
Their database, not mine. It's a big flat thing.
I was joking about the bit datatype thing, but if you really have 1200
columns - not rows, columns - the firing of the original database designer
should be an auditable event.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf
From: Les Mizzell [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 9:36 PM
To: CF-Talk
Subject: Re: Change Log on database updates - need some ideas
Bob Smith, owner of Data Sys One, performed the following updates:
1. Changed SOX compliance date from 11/12/1999 to 2/12/2001
On 2/21/07, Dave Watts [EMAIL PROTECTED] wrote:
Their database, not mine. It's a big flat thing.
I was joking about the bit datatype thing, but if you really have 1200
columns - not rows, columns - the firing of the original database designer
should be an auditable event.
+1!!!
Owch... if
Les Mizzell wrote:
I shouldn't complain too much, as they don't care how much it costs and
pay quickly - but, is there a more efficient way of doing this?
triggers.
~|
Deploy Web Applications Quickly across the enterprise
On 2/20/07, Paul Hastings [EMAIL PROTECTED] wrote:
Les Mizzell wrote:
I shouldn't complain too much, as they don't care how much it costs and
pay quickly - but, is there a more efficient way of doing this?
triggers.
AJAX. Field-based editing with a simple log. =]
I shouldn't complain too much, as they don't care how
much it costs and pay quickly - but, is there a more
efficient way of doing this?
triggers.
AJAX. Field-based editing with a simple log. =]
I'm sorry, but that, by itself, is a very silly answer.
AJAX is display technology.
Dave Watts wrote:
I shouldn't complain too much, as they don't care how
much it costs and pay quickly - but, is there a more
efficient way of doing this?
triggers.
AJAX. Field-based editing with a simple log. =]
I'm sorry, but that, by itself, is a very silly answer.
AJAX is display
On 2/20/07, Judah McAuley [EMAIL PROTECTED] wrote:
Dave Watts wrote:
I shouldn't complain too much, as they don't care how
much it costs and pay quickly - but, is there a more
efficient way of doing this?
triggers.
AJAX. Field-based editing with a simple log. =]
I'm sorry, but
29 matches
Mail list logo
