Hi Guys
Alexander on the newsgroups has found an interesting bug. It seems if you update an Alias file it also opens the base file.
Test App & dct attached. testbug.zip (41.7 KB)
From Browse menu add record
Then From Browse Menu Test Update
I have 11.13505 and this seems like a bug to me
The Alias FM class may need to use the base FM class which could explain this situation, namely there might be (record/row)/(file/table) locking code doing stuff.
Another way to do alias files it to import the file/table into the dct with a unique name and prefix but in the filename field give it the same data source.
All the file locking should still work then and just be treated as another instance of the program running.
Interesting theory,
I would think any locking would be done using the alias buffers etc. The alias is treated as a seperate file, from the clarion viewpoint it should act just as you suggest.
but even if it does open the base file, in any case it should not leave the base file open!
Other clarion version do not show that behaviour
I dont think/didnt think you can/could do CRUD on alias files in the FM classes though, since the ABC classes first appeared, so that would be C5 or C55 times? I only went ABC at C6, before then legacy since CW1.5.
CW1.5 didnt have alias table/file facilities in the dct back then so the work around was just treat it like a magical different file and make sure oplocks was handled properly on the workstations and server.
I havent downloaded the file and looked at it, but yeah you would expect consistent behaviour ie if alias file opens base FM file, then it should close it, but this might be part of the LazyOpen/LazyClose stuff, because NT File system is supposed to be slow compared to other *nix file systems when opening and closing file handles. Never tested but I know Stamos always like to recommend a Buffalo NAS type device as a place to store the tps files as it handled the record locking properly on the network share, joys of a single boarch computer like a RaspberryPi bolted onto a HD in a powered enclosure.
There is a lot of information stored in the NT files system though, in some respects its like a giant database with many behind the scenes properties for each file which we will never normally see in the file manager or some api’s.
here’s been a bit of discussion on Skype over this.
And I’ve looked into the ABC Classes.
It’s been this way for a long time. The Base file ONLY stays open under ABC and ONLY if lazy open is on. ie on the file control tab, uncheck the box at the bottom that says defer open until used and the base file stays closed.
So I still think it’s a bug.
A bug in my books is where an app doesnt do what the customer wanted, if its a bespoke system, but something like Clarion where lots of different customers exist, SV have to say what the intended behaviour is.
Me personally, I would expect CRUD to be possible in the normal FM class and in the alias class, so yes a bug with the long running situ since the introduction of ABC.
As to this current bug, if it doesnt open the base file, what file would you expect it to open and why?