Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 3 Jahren, 6 Monaten
Letzter Beitrag:
vor 3 Jahren, 5 Monaten
Beteiligte Autoren:
Al, DarrenF, Arie, Allard, Stefan Bentvelsen

[WD19] Does anyone use the inbuilt logging ?

Startbeitrag von Al am 28.12.2014 00:36

Hello All

I have a situation where I need to track changes to data records and I am trying to decide whether to write my own process to capture the "before change" data or to use the inbuilt WDLog. I am not interested in being able to restore data from logs, just track the changes.

In terms of using FileTomemory() , the help text is no real help at all, but I assume it would be possible to save the current record buffer from one file and then write that data out to a different file using MemoryToFile(). I have never used the structure variable - is there a way to automatically create one where the structure members are the same as a file field list ?

It may be simpler to use HlistItem() and ControlClone() to build a memory table and then use FileToMemoryTable(). I could build this as a generic parameter driven process.

One problem I see with the WDLog process is that on my reading of the help, it looks like the log files are deleted/cleared when the WDModfic is run on the file being logged - is that correct ?. If that is the case then there is not much point in using the inbuilt logging as all the history would be lost if the fie structure changes.

From the Windev help:When the automatic modification of data files is performed on the logged files: The log files are automatically saved. The log files are flushed.



Hi Al,

instead of using a structure, may be you could use a record variable without specifying the file name. If you put a record in this variable, you can use the members direct.

lrecMyRecord is record

lrecMyRec = MyTable


von Stefan Bentvelsen - am 28.12.2014 12:02
Hello Stefan

Thanks for the suggestion. I went with something similar as I needed a quick one off solution. I used a view to hold the current record as a temporary solution while I figure out something better.

PCSoft would do well to look at the old Foxpro Scatter Fields To Array and the opposite Gather/Append From Array These commands automatically put all the fields in the current record buffer into an array (naming the array members correctly with their field names) and then allowed you to append them onto a file which was just perfect for logging.
There appear to be no tools in Windev to easily, without handcoding and without indirection to emulate these commands that I had in Foxpro back in the 90's

Part of the issue is that in an edit window I may change some of the data in the fields as I go and then hmodify() on save so I can't just re-read the record on save to get a "before" version without then loosing those field changes. I am looking at setting up a method using an alias and re-reading that file as a "before" record. I can then do a hcopyrecord() of the alias record into the log.



von Al - am 28.12.2014 21:36
Hi Al

So you want to be able to reset a record after you have made changes with hmodify? . How many versions do you need resetting to?

For instance:
You make changes save with hmodify. Make ano ther change save with h modify. Now you made two changes. Do you want to be able to undo the last change onley or both changes?



von Allard - am 29.12.2014 18:56
Hi Al,

did you ever had a look at Peter Holemans project about his OOP framework?

It looks like you are looking for something like that.
Putting all data handling stuff in classes, which act like your FoxPro arrays.
Then you can do whatever you want after/before reading/writing.

von Arie - am 29.12.2014 20:12
Hello Allard

Luckily I don't need the logging for restore purposes, I just need to hold a log of changes to the data and who made them.


von Al - am 31.12.2014 08:32
Hello Arie

I can barely spell OOP, much less program it but I will have a look, thanks.
The view option is actually working quite well because I only have to track about a dozen files and I only need the "before change" state of a record. I created the data sources for the views in the project init and because I have centralised add, modify and delete functions all I need to do is check, in my RecordModify() proc, if a view has a record with hnbrec(ViewName). If it does, I copy the view data into the log file and delete the view record. There is very little coding and the view will always capture the current file structure automatically. It is probably a bit memory hungry but that doesn't seem to be an issue with today's workstations.


von Al - am 31.12.2014 08:43
Hi Al,

Could I just ask why you've discounted the inbuilt logging?

von DarrenF - am 31.12.2014 09:42
Hello Darren

I think, from reading the help, that the log files are deleted whenever there is a wdmodfic run on the files. If that is the case then they are no use to me as a permanent log.


von Al - am 31.12.2014 11:13
to be honoust I do more or less the same as you, to be able te replicate data changes from a offline system to the main system.

The OOP just seperates things to a certain level, which is great in some situations (like reuseability in WB or WM). But it doesn't really change the way it works, in terms of functionality. You will still need to implement the logging.

von Arie - am 31.12.2014 11:52
Yeah, it's a bit unclear in the Help because it says the log file is saved before being cleared.
I suppose the logging process could also be implemented via Triggers as well?

von DarrenF - am 31.12.2014 12:11
Hello Darren

Although I don't use OOP I do have a lot of global procedures that run most things so the code that runs off the Modify/Alter button does a re-read and then fills the window controls. At that point is is quite simple to create a view of the just read data for my log entry.
I think my habit of directly writing data from a control into the underlying data file buffer before the hmodify() would stop me from getting a clean "before" copy of the data using triggers.


von Al - am 31.12.2014 12:27
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.