Thanks for the help I got it working. However I had to wrap the deserialize call in a try/catch as it always threw an serializationexceptions:

Thanks! I'm not too familiar with the IO class and streams. I was having trouble getting the byte array into the stream. Again not too hard once you understand it!

Here is an example if you have a file saved to disk.  In the auditing sample, the byte array will be given back to you through the delegate, so you would skip the part of loading the byte array.

Way too easy...



Now, how do I get byte array back into the object via deserialization? Or probably more to the point, how do I turn the array into a memory stream?

Since it is a byte array, you can put anything you want into it.  You can read a file from disk into a byte array and dump it in there, or whatever you want.  It doesn't have to be serialized, it just has to be formatted as a byte array.  When the reader becomes available, we will provide a delegate that will allow you to attach any type of reader you like so you reverse what you did going in and show it to the end-user however you would like.  But if you want to serialize something and convert it into a byte array, here is a sample of how to do that:

I've been messing around with this and have run into a problem, born from pure ignorance.



How do you get a serializable object into a Byte array()? It's probably simple, but I'm not getting it.



Thanks!

SF auditing requires that you have RBS.  All of this is done through the security side so that you can turn on auditing for one user and not another, etc.

But if you set the AuditDataChanges property to True, and then the current user supports auditing (which you cannot override at the moment), and you have your app setup with security...AND you have the SFSAuditDataChanges, SFSAuditDataFields, and SFSAuditEvents deployed to the same database as your other RBS tables, then it should work.

You can also call the audit methods directly by using the Auditor class in security:

You can store anything that you want in the Byte Array parm.  We will have a delegate that you set in the viewer that gets called to determine how to show or view that data.  This approach allows you to store literally anything you want as additional data within the audit record.

I did notice the AudiDataChanges and NeverAuditDataChanges properties in the BO but could not find any information about those in the help or the forums.  For now I don't need any viewer because these fields will be shown in a StatusBar for some forms only.  So if there is something in the framework now I could use for this specific situation then I would like to, if not then I will have to go with the BO base class approach.

I agree that Audit Trail is a complicated stuff and in my VFP projects I used it in just 2 or 3 projects and in some specific forms to avoid the slow down of the DBF tables with memo fields.

Edhy Rijo

We actually take a similar approach within our medical application on the CreatedBy and CreatedAt fields.  As for the editing fields, we have started implementing some auditing features on certain tables so that you can determine what was changed by the user.  Just know which user and the time is not generally enough...the next question is always, "what did they change?"

There are actually a number of ways to go about this...you can use event hooks that you can manually implement on your base BO (i.e. Beforesave, etc.).  We also have some classes that are actually in the framework to audit a BO record...though I will not tell you about all of that until we have the viewer ready

We are implementing auditing several different ways within our medical application because some things are more sensitive than others...but the more auditing that you add, the slower things will become.  So this is one of those things that has to be used with caution.

Thanks again Bill, a base BO makes sense, will try that path.

Edhy Rijo