Walter Meester
HoogkarspelPays-Bas
>I know, However this only works on PKs, not on other columns. OF course there are a number of feartures like SET NEAR and SET FILTER, TAG orders etc that don't come in ADO.NET
>I believe your words were 'no SEEK on local data'. You are now qualifying your statement.
I should have said above that those features are respected by the SEEK() command. What I ment to say here is that the FIND() method does have the same functionality in one specific circumstance: Searching on a PK. In that light, FIND() is hardly the equivalent to SEEK()
As to locate, replace and possibly a few other commands: Of course you can roll your own, but it still is your implementation, not a global one that is use throughout the .NET community. When writing you own solutions, you spend a lot of time implementing, testing and debugging, while *if* the commands where available natively, you would not have that problem at all.
Walter,
>Correct, to create a primary key and then a FIND (analogous to a SEEK), it must be on a unique key.
>
>You can do a ROWFILTER. You can also create multiple dataviews on a datatable with different sort orders. You can also specify in a lookup (by using different special characters) whether you want an exact match or partial match.
>
>As I mentioned months ago, I wrote a generic LOCATE function that receives a collection of column(s) and a lookup value to return the datarow(s). I am not denying that I had to write some code to do the same things that VFP has in one command.
>
>But this argument that it 'adds complexity, increases the possibility of bugs' is no more valid than it would be if argued against VFP people who wrote some additional code to do things with, say, the Win API that VB supported 'out of the box'.
>
>Kevin
Précédent
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement