The flat file approach is also an option for us, thanks for suggesting it
Akila. At the moment we dont have a feature to make use of audit
information and it is not a priority for us to implement. So we will
revisit our options latter on if we do decide to implement this.
On 23 October 2016 at 0
Hi,
What exactly is the purpose of Audit table or tables? Will those be used to
query the history and display it to the user through the system? Or is it
only for auditing purposes in which APIM will never directly query the data
but a separate system or tool will use.
If it is the latter case th
On Fri, Oct 21, 2016 at 12:10 PM, Bhathiya Jayasekara
wrote:
>
> On Wed, Oct 12, 2016 at 12:30 PM, Inosh Goonewardena
> wrote:
>
>>
>>
>> On Tue, Oct 11, 2016 at 2:40 PM, Uvindra Dias Jayasinha > > wrote:
>>
>>> Thanks for the feedback, some interesting points were brought up
>>>
>>> @Abimaran,
On Wed, Oct 12, 2016 at 12:30 PM, Inosh Goonewardena wrote:
>
>
> On Tue, Oct 11, 2016 at 2:40 PM, Uvindra Dias Jayasinha
> wrote:
>
>> Thanks for the feedback, some interesting points were brought up
>>
>> @Abimaran, the problem with maintaining a rigid structure like old/new
>> column is that
On Tue, Oct 11, 2016 at 2:40 PM, Uvindra Dias Jayasinha
wrote:
> Thanks for the feedback, some interesting points were brought up
>
> @Abimaran, the problem with maintaining a rigid structure like old/new
> column is that if a user changes the value of 5 columns at a given time
> that would mean
On 12 October 2016 at 10:54, Lahiru Cooray wrote:
>
>
> On Tue, Oct 11, 2016 at 1:44 PM, Sanjeewa Malalgoda
> wrote:
>
>> I think we can manage audit table while still having CREATED_BY,
>> CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that
>> approach we may never need to do ta
Thanks for the feedback
On 12 October 2016 at 09:33, Abimaran Kugathasan wrote:
>
>
> On Tue, Oct 11, 2016 at 10:34 PM, Lakmali Baminiwatta
> wrote:
>
>>
>>
>> On 11 October 2016 at 14:40, Uvindra Dias Jayasinha
>> wrote:
>>
>>> Thanks for the feedback, some interesting points were brought up
On Tue, Oct 11, 2016 at 1:44 PM, Sanjeewa Malalgoda
wrote:
> I think we can manage audit table while still having CREATED_BY,
> CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that
> approach we may never need to do table scan of audit table while fetching
> updates. So each update
On Tue, Oct 11, 2016 at 10:34 PM, Lakmali Baminiwatta
wrote:
>
>
> On 11 October 2016 at 14:40, Uvindra Dias Jayasinha
> wrote:
>
>> Thanks for the feedback, some interesting points were brought up
>>
>> @Abimaran, the problem with maintaining a rigid structure like old/new
>> column is that if
On 11 October 2016 at 14:40, Uvindra Dias Jayasinha
wrote:
> Thanks for the feedback, some interesting points were brought up
>
> @Abimaran, the problem with maintaining a rigid structure like old/new
> column is that if a user changes the value of 5 columns at a given time
> that would mean 5 di
Thanks for the feedback, some interesting points were brought up
@Abimaran, the problem with maintaining a rigid structure like old/new
column is that if a user changes the value of 5 columns at a given time
that would mean 5 different inserts to the table, when in actual fact it
was a single tran
I think we can manage audit table while still having CREATED_BY,
CREATED_TIME,UPDATED_BY, UPDATED_TIME in same tables. So with that
approach we may never need to do table scan of audit table while fetching
updates. So each updates will recorded in separate table while original
table having all rel
Hi,
What about having one AUDIT table with below schema structure?
ENTRY_ID PK
TABLE_NAME VARCHAR
FIELD_NAME VARCHAR
OLD_VALUEVARCHAR
NEW_VALUE VARCHAR
ACTION_BY VARCHAR
ACTION_TIME VARCHAR
It's rare, that, we have to update all the Columns in a si
13 matches
Mail list logo
