[TIP] Save searches with Servoy 3

by Riccardo Albieri

The dynamic dev-team just introduced a very powerful, new feature in Servoy 3RC1: now it's possible the get the SQL used by Servoy to generate a foundset using two instructions (databaseManager.getSQL and databaseManager.getSQLParameters).

Why it's so powerful? Well: did you ever wonder how nice would it be to have a quick way to store user's searches? Now it's possible with very little effort.

Just put a onSearch method that grabs the SQL and the related parameters, like:

controller.search()
//get the SQL of the current foundset
globals.SQLPark = databaseManager.getSQL(foundset)
globals.SQLParamsPark = databaseManager.getSQLParameters(foundset)

After that, you can load this foundset whenever you want, just using:

controller.loadRecords(globals.SQLPark, globals.SQLParamsPark)

Of course, this is just an example. You may want to build a more articulate procedure, that stores the saved searches in real columns and not in global fields and so on...

[image unavailable: ]

Enjoy.

Comments (5)

Marcel Trapman 2006-08-31

Nice tip Ric! Could have saved a lot of time in the old days ;)

Harjo Kompagnie 2006-09-03

But has this function also the limit of 200??

Graham Greensall 2006-09-14

Great tip Ric - so many new features in Servoy it's easy to miss some so your article was very useful. Wonder if you could expand on saving into 'real columns'. Am using your technique but can only get it to work with the Globals - trying to store in fields for later re-use fails. Could you expand a little please? It's worth several beers at SW !! Thanks in advance. Graham Greensall

Riccardo Albieri 2006-09-14

>But has this function also the limit of 200?? Actually, I didn't test it, but you can load some more record into the underlying table of my little example file and see what happens :-) My guess is that it's not limited, but I'm not sure...

Riccardo Albieri 2006-09-14

>Am using your technique but can only get it to work with >the Globals - trying to store in fields for later re-use >fails. >Could you expand a little please? When I built this small example I used two globals to store the SQL code and the parameters just because it's quicker to set up. But if you build a table, say "saved_searches" with 2 columns where you save those data, there should be no difference and you would have the chance to save and restore more than one search. Just guessing: are you sure the column types are correct? The params need a media/blob field, not a text field.