Default RecordSet 50?

Alex_Chow

Belias wrote:

Yes, this is what i meant...MAYBE we'll have to modify a lot of findsets in the standard code, and this will be painful during an upgrade...as you said, it would be an optional parameter, but if you begin to use it, you have to merge it with all future versions; moreover, for an add-on solution, you'll probably have to refine the parameter everytime depending on the specific customer.
it's a difficult choice :-k
Some hints from MicroSoft guys?

I'm not sure if I agree that it'll be a pain to upgrade... You're only upgrading your own custom code.

The add-on solutions wouldn't define the number of recordsets if they intend their add-ons for popular use.

Belias

Maybe i'm too lazy, also for a programmer, but i think that if the parameter will be wide used under standard objects (i mean, for example -and for hypotesis-, modifyng all findsets of codeunit 90), it will be a pain to change single lines of code..
about the add-on you're right: modifications for single customers only, shouldn't be in an add-on.
and what about different companies?the source code will ever be the same (unless you condition your FINDSETs to COMPANYNAME in some way, but this is weird to develop)

generic

If you are looping through all the records, why would you only return a given set X Records and then after that given set create cursor.

After all you are going to loop through all the recordset, why switch to a cursor?

On Service tier you'll be consuming more memory, but memory is cheap and get a 64 bit version of service tier. And I know that will take another 4 years.

So based on Jesper Falkebo post it purely a memory issue.

With having 4 gig on each workstation, how much heap memory are we talking about.

David_Singleton

You guys really do need to get an understanding on what hard coded means.

If there is a field that you can enter a value, that is NOT hard coded. If you have to open up the developer and modify C/AL somewhere then it IS hard coded.

Its a very simple concept.

Slawek_Guzek

David Singleton wrote:

If there is a field that you can enter a value, that is NOT hard coded. If you have to open up the developer and modify C/AL somewhere then it IS hard coded.

... and when system calculates some value using other some other values (like number of records in given table for example) ?

DenSter

generic wrote:

If you are looping through all the records, why would you only return a given set X Records and then after that given set create cursor.

After all you are going to loop through all the recordset, why switch to a cursor?

I never understood that either. It is really the root of the issue here. If the looping would simply act consistently, we wouldn't have to have this whole discussion.

generic

DenSter wrote:

generic wrote:

If you are looping through all the records, why would you only return a given set X Records and then after that given set create cursor.

After all you are going to loop through all the recordset, why switch to a cursor?

I never understood that either. It is really the root of the issue here. If the looping would simply act consistently, we wouldn't have to have this whole discussion.

I guess we would never know.