SQL Audit Logging - Latest Pre-Release

[iRadiate]

Can anyone who is using the new SQL Audit logging feature confirm whether it is working in the latest pre-release (5171-5137)?

Thanks,
Stephen

[Davidk]

Re: SQL Audit Logging - Latest Pre-Release

It looks like a new field was added to the SQL Audit table since this feature was first introduced... new field added in Build 5151... "User field 1".

As usual, no quality testing was done to ensure this wouldn't adversely affect existing uses of this feature.

My table did not contain a field for userfield1. So... the Audit Table feature stopped working. Here is the section of the release notes...

Audit Table Feature - User Defined Field - You can now add a user defined field to the audit table to capture any additional information that you want at the time the audit table is updated. If you set the value in a special session variable called session.__audit_userfield1, the value in this variable will be written to the user defined field when the audit table is updated. If you want to store a significant amount of information in this field, consider creating a string of JSON data. The JSON data can have a large number of properties.

It should read... "You MUST NOW ADD a user defined field...". Alpha should have gracefully handled this new field being missing.

Further, even though the doc on a5Helper_writeToAuditingLog is badly written, a result from this never exists... whether the call is good or not.

Have a look in your Project Properties, Audit table, Field map, to see the new field. Add a field to your table, makes sure it's mapped... and SQL Audit Table will start working again. It's not a tough thing to test, but Alpha won't, or can't, seem to test these changes.

[iRadiate]

Re: SQL Audit Logging - Latest Pre-Release

David,

WOW! Just WOW! Thank you.

Please see pm on this issue.

[iRadiate]

Re: SQL Audit Logging - Latest Pre-Release

Yep, that's exactly what it was David. And Alpha refused to help me on this bug!

[mikeallenbrown]

Re: SQL Audit Logging - Latest Pre-Release

Maybe Alpha could hire David to QA their work.

[Ben S.]

Re: SQL Audit Logging - Latest Pre-Release

Not a good run this week. Is the regular QA guy on vacation?

[Selwyn Rabins]

Re: SQL Audit Logging - Latest Pre-Release

Yep, that's exactly what it was David. And Alpha refused to help me on this bug!

It would be best if you were accurate in your statement here. Your original bug report did not have a test case. So we built our own test case and could not duplicate the problem. We communicated this to you. This is hardly refusing to help.

[iRadiate]

Re: SQL Audit Logging - Latest Pre-Release

It would be best if you were accurate in your statement here. Your original bug report did not have a test case. So we built our own test case and could not duplicate the problem. We communicated this to you. This is hardly refusing to help.

Why are you dragging this up again?
That was posted before numerous emails back and forth to each other which, in the end, I understood we were going to be professional and move on from this? See my email to you dated June 29, 2018. It is you who is twisting the accuracy of my statement.

Let's be crystal clear about this since you wish to re-air this in the forum.

This issue would NOT have been seen by you with a test case because you added a SQL field in the audit table after initially introducing the audit feature. Therefore, that field did not exist in my table. Updating the pre-release did not add the extra field to the audit table. Reverting back to a prior pre-release made the audit table start working again. Also, there was no error trapping to indicate what the problem might have actually been. The audit table simply stopped working completely once you added a new field.
I could not resolve the issue because I was not aware that you had done this. So, I asked you to test my application against my database. This most definitely would have revealed the problem to you. Your response to my request was, and I quote, "i am sorry, but i don't have time." What exactly am I misinterpreting about that reply?

David Kates was the person who actually helped and informed me what was going on. Otherwise, this would still be an unresolved issue for me.

[kkfin]

Re: SQL Audit Logging - Latest Pre-Release

Now you Stephen can't see forest for the trees.

You did drag the subject in Message Board not Selwyn. You did say in post #4 "And Alpha refused to help me on this bug!" You did get help and your problem solved but you still needed to attack Alpha? Seems personal reason to me.


Then when Selwyn answered to you attack you get angry. You seem to think that "I am sorry, but I don't have time" is synonym to refusing to help. Seems to me Stephen that it is time to watch mirror and not blame others when you do not understand why you get errors and can not solve them.

[frankbicknell]

Re: SQL Audit Logging - Latest Pre-Release

A lot of this could be solved if Alpha did a better job of documenting their changes. I have the same issue as Stephen. If it was not for David Kates solving it I would have had to submit a bug report too. I see only criticism not an attack on Alpha.

[iRadiate]

Re: SQL Audit Logging - Latest Pre-Release

Thank you Frank. Facts are not an attack. Frustration is not anger. A lot of people have expressed frustration over these types of issues dating back a long time.

I have to say I cringe every time there is a new release, and that goes for both official and pre-releases, because I know there is a high probability that something in my application will break.
Alpha puts us into a no win infinite loop with bug reporting. If you report a bug and you are not using the latest pre-release you are told to try the latest pre-release first. The stipulation on pre-releases is don't use them on a live system. That necessitates having a completely duplicated testing environment that exactly mimics the live system. This is something that unfortunately I cannot do in my environment.