Hi,

From what I understand, skipping is not featured in the latest LLBLGen Pro? Are there any workarounds, ways to achieve more precise fetches such as skip 3, take 10 etc.

If not, are there any plans to implement this?

Cheers, Frank.

You are right, Skipping is not supported, and there is no news on whether it will be or not. If you want that, you will have to look into a way to specify a page size of x which is equal to the skip size. The number of rows to skip has to be equal to a multiply of the page size. more info...

No plans yet to support this. Technically it's not difficult, but our inner framework is build around pagesize + pagenumber, so if we add skipping, we need a lot of extra overloads to methods on the adapter and other persistence interfaces, and as the amount of methods is already large, we didn't want to add another set. (each method with paging directives needs a skip variant as well).

Is there any way I could do the above, could you point me in the right direction, even if it's hacky? Nothing elegant, just any method to achieve traditional skip / take functionality? I'm using self serv.. I've only come across the need for this a couple of times, so I could wrap it in a method, and remove it in the future should this be supported.

Cheers, Frank.

BTW: thanks to LLBLGen, my site now handles >3.5m visitors a month on a single 8-core server (sql + iis same box). LL has allowed for a cleaner code experience overall that translated into efficient use of processes, caching, fetching cycles etc. Cheers for that! LL is probably the most important thing that has happened to my company over the last 8 years.

Can you modify your code to use TakePage(pageNumber, pageSize) instead?

@Walaa As an example..

There are parts of my site that display partial views of lists.. this is the code that fills in the area around those lists (via ajax and so on). Much like the 'load more comments' parts of comment streams.

I can make my code use takepage / equal sized paged data blocks. But we have a great deal of pressure on the server, and need everything to be as efficient as possible. In many cases, only 3 / 4 items are loaded on the first load (the pagesize is variable, and so is the position of those elements within the overall resultset) with the option of continued page growth of the list if they wish.

Rows 1-4 might be loaded on first page view. User clicks 'more' (Second query) Additional 10 rows are displayed. (rows 5-14 <- cant be done at the moment) User clicks 'more' Additional 10 rows are displayed.

I could make this work by exluding the RowIDs that are displayed from the second query, and continuing paging as normal.

(thanks for the great feedback! )

That scenario indeed can be done by using a fetch using MaxNumberOfItemsToReturn set to the pagesize*pagenumber + initial rows, and no paging, and a where clause with the id's already seen. However this is a bit hacky and gets slower when you move over the set.

As you're effectively paging over the set using pages of 10 rows, you can use the MaxNumberOfItemsToReturn parameter as well. So set it and also set the page number / pagesize (pagesize to 10). This of course out of the box doesn't do anything differently.

In the SqlServerDQE sourcecode, you should change the following: - in CreatePagingSelectDQ, you should pass to the maxNumberOfItemsToReturn to the mangle method you're using (so the 2005 one if you're using sqlserver 2005 or higher and have set the compatibility mode to that value (it's the default in v3). - In the mangle method, e.g. ManglePageSelectDQ for sqlserver 2005+, you add the parameter maxNumberOfItemsToReturn (long), and at line 923 and 924, you add maxNumberOfItemsToReturn to the numbers set as values on the parameters.

This way you can specify skipping. Not from linq, but from our own api you then are able to do so.

Compile the DQE code using your own strong key (reference the shipped ormsupportclasses dll) and reference your dqe instead. That's it

We normally don't get that much bugfixes in this assembly so it should be fine.

wow thanks Otis - very much appreciated -> Exactly what I was after!

Cheers, Frank.