var _fs = databaseManager.getFoundSet(server,tablename)
_fs.loadAllRecords()
_fs.setSelectedIndex(1)
var _fs1 = _fs.fs_to_other_fs
_fs1.find()
_fs1.field = value
_fs1.search()
var _fs2 = _fs.fs_to_other_fs
var _newfs = databaseManager.getFoundSet(server,tablename)
_newfs.loadAllRecords()
_newfs.setSelectedIndex(1)
var _fs3 = _newfs.fs_to_other_fs
After this _fs1, _fs2 and _fs3 contain the same filtered foundset (only those records that meet the relation fs_to_other_fs and meet the find criterium field=value).
I would expect that _fs3 would contain all the records that meet te relation fs_to_other_fs.
Also that _fs2 contains the filtered result is in my opinion questionable.
this is how Servoy works,
Related foundsets do have 1 instance per related keys.
So of you aks related_fs[10] where 10 is the fk value for some relation
you get that instance
if you filter that one then in what ever form you go to that same related_fs with that same 10 foreign key value you will get the same instance. (which is filtered)
There can’t be 2 instances of the related foundset of the same key, that would be quite confusing because when are you getting which one?
If you really want something like that you can use unrelated() to create a copy
That means everywhere where I use a related foundset I will have to question whether this relation was not used in a find/search earlier on somewhere else in the program. To be safe I have to call loadAllRecords() allways (I am not sure what another programmer does in his methods/forms/modules/solutions) when using a relation… Or is there a way to determine whether a related foundset is a result of a find/search?
to always just call loadAllRecords() will kill performance of your application, because you do use normally a lot of related foundsets and that would cause many refresh queries.
I don’t think there is an easy way maybe databaseManager.getSQLParameters() but then you have to compare that output with the default relation parameters.
Maybe if you really search specif in a related foundset it is better to first just unrelated.
In Foxpro we were constantly saving and restoring table filters and indexes and recordpointers to maintain a certain table state.
I thought those days were gone within Servoy…
It’s too bad because I love the easy use of a related foundset so much !
I hope I can remember during programming not to search in a related foundset
I had also a little discussion about using controller.find()/.search() in a related foundset with Johan. The way I have now changed my code is working correct and fast. Have a look at: http://forum.servoy.com/viewtopic.php?f=22&t=16210
Hans Nieuwenhuis:
I am not sure, but if you create another relation with the same parameters
and use that, it will be a different foundset
Hans,
The combination relation-name+left-arguments refers to a related foundset that is globally the same for the client.
So yes, different name, different foundset.
var _fs = databaseManger.getFoundSet(server,tablename)
_fs.loadAllRecords()
_fs.setSelectedIndex(1)
var _fs1 = _fs[relation_name]
I expect in foundset _fs1 all the records to be present according to the relation parameters and not less records !
I consider this Servoy (app.server caching) behaviour as unwanted, the servoy relation result is now unpredictable (dependent of last search action in related foundset with same parent)
I agree that may give unexpected results.
But changing this is a big change in the internals of Servoy because we cannot stop the caching.
And what about solutions that depend on related foundsets that are filtered?
Note that this is the behaviour of Servoy since day 1.
Please file a case for a future version.
Until then the workaround is to use unrelate() before doing a find on a related foundset.