MSibai:
can we ask for an enhancement request of the loadAllRecords method to have an optional parameter called [forceLoadingAllRecord] and to be defaulted to false ?
loadAllRecords([forceLoadingAllRecord])
If it has been set to true the limit clause is to be neglected.
Do you agree on this ??
MSibai:
New support ticket has been opened with the number 99657.
Could we have any comment on this ??
It is a feature request and as such is on the list of considered items. If you need it urgently you can contact sales@servoy.com for a quote.
hi, that’s funny, I bumped into the same issue today, with one of my customers!
Is some cases it would be very handy indeed!
Great to hear it’s already on the features-list!
Yes - and there is a bigger issue too - the reason for the 200 record limit is that’s the biggest number of items allowed in a SQL “in” clause.
So - getting a row - then the 99 rows “before” and “after” it can cause big problems - and is very difficult to do without getting the entire recordset (which causes huge problems in terms of performance).
bcusick:
Yes - and there is a bigger issue too - the reason for the 200 record limit is that’s the biggest number of items allowed in a SQL “in” clause.
So - getting a row - then the 99 rows “before” and “after” it can cause big problems - and is very difficult to do without getting the entire recordset (which causes huge problems in terms of performance).
Hi Bob,
Read my suggestion earlier in this thread carefully.
There is no need to load more than 200 records. I can write this kind of code myself using Servoy – but that smells just as bad as a F***Maker workaround.
bcusick:
Yes - and there is a bigger issue too - the reason for the 200 record limit is that’s the biggest number of items allowed in a SQL “in” clause.
So - getting a row - then the 99 rows “before” and “after” it can cause big problems - and is very difficult to do without getting the entire recordset (which causes huge problems in terms of performance).
Hi Bob,
Read my suggestion earlier in this thread carefully.
There is no need to load more than 200 records. I can write this kind of code myself using Servoy – but that smells just as bad as a F***Maker workaround.
Which of your suggestions? Using OFFSET (one of your suggestions) is not viable as it does not work on all databases. Additionally some databases (including older versions of Postgresql, not sure about the latest) will go fetch everything independent of what offset you specify.
Having programmed quite some apps in my life I’m still surprised by the apparent need of jumping to record 110,000. Why jump there? Give me three real life examples when you absolutely need this.
OFFSET was added to PostgreSQL in 1999, long before my time using SQL databases. MySQL uses LIMIT. In my own work-around-code I had to check the type of database and add in either syntax.
I suppose the problem may be that this is not covered by the SQL92 standard. Isn’t there a newer standard?
I have many users working through lists and having to go to the bottom of the list one or more times to get where they want to get. They may have a reason to see something in context, such as the full history of an customer or supplier account. At the moment I can’t easily jump down the list to a certain point to help them.
Others users work through lists of people, maybe checking email addresses, copying people to other lists. User goes home for the day, comes back the next morning and want to come back the next day and start half-way down the list.
Looping 200 records at the time is not a good solution.
If have loaded all records, I expect to be able to jump to any record. At the moment this is not possible.
It is better to log warnings in developer if the dataset is large, rather than not having this functionality because the dataset MIGHT be large. In most cases it will be datasets of moderate size.
Another reason: sometimes I want to loop a foundset in reverse since processing the records may remove them from the foundset and I don’t want the hazzle of having to adjust my position accordingly.
OFFSET was added to PostgreSQL in 1999, long before my time using SQL databases. MySQL uses LIMIT. In my own work-around-code I had to check the type of database and add in either syntax.
I suppose the problem may be that this is not covered by the SQL92 standard. Isn’t there a newer standard?
I have many users working through lists and having to go to the bottom of the list one or more times to get where they want to get. They may have a reason to see something in context, such as the full history of an customer or supplier account. At the moment I can’t easily jump down the list to a certain point to help them.
Others users work through lists of people, maybe checking email addresses, copying people to other lists. User goes home for the day, comes back the next morning and want to come back the next day and start half-way down the list.
Looping 200 records at the time is not a good solution.
If have loaded all records, I expect to be able to jump to any record. At the moment this is not possible.
It is better to log warnings in developer if the dataset is large, rather than not having this functionality because the dataset MIGHT be large. In most cases it will be datasets of moderate size.
Another reason: sometimes I want to loop a foundset in reverse since processing the records may remove them from the foundset and I don’t want the hazzle of having to adjust my position accordingly.
Taking into account that a user can only read (part of) one screen at a time I still dont get your point. You can load any record in Servoy, in any order and jump to any record if you really want to but what I’m reading here is missing functionality: if a users needs to remember himself what he has to do the next morning by record number I’d recommend changing the software such that this is not necessary: it sounds very prone to user errors to me that can easily be addressed by improving the workflow of your software. If you need to go to a bottom of the list the easiest and most intuitive way of doing so is reversing the sort order.