Workaround for 254 field max in cursors

[insania]

Hi

I was wondering if anyone knew a way of extending the 254 field limit in a cursor if using an SQL database back end such as PostgreSQL, mySQL or MS SQL.

For instance if creating a report from VFP we want to be able to select more than 254 fields into the cursor in case different users have different requirements of the report.

Thanks

 

[insania]

So if I needed to get over 254 fields you would recommend multiple cursors? Say perhaps a cursor per table?

Or is there another way of doing what im after?

 

[baltman]

Sounds like you may want to get a better idea of user requirements before you do too much programming.

Yes, a cursor/view for each table would mimic the (hopefully) efficient design of the back end.

You might want to combine/filter a little to make the data in the cursors/views more efficiently feed into your reporting/processing goals.

Brian

 

[insania]

Thats the problem, each user might have completely different requirements for the report so all of the fields that may be needed are being passed through incase one of them is needed. Then the report is manipulated after that for each user (I think this is pretty much how the software works for this)

Is there a method that could be used to combat this? Im not very sure how else this could be achieved is all

 

[baltman]

What about code that builds the Cursor/View based on what the report needs?

 

[insania]

OK, so basically there is no work around available for one cursor.

If we want to have more thn 254 fields in a report it comes down to either multiple cursors or different reports for each user.

Is this correct?

 

[Mike Lewis]

Insania,

We've talked about this before, so forgive me if I'm going over old ground.

I feel the direction you should be going in is to generate a separate cursor for each report. Get the list of fields from the user, then programmatically build a SELECT statement to get those fields into the cursor (along with the fixed fields -- the ones that appear in every version of the report).

In this scenario, you'd only have one report file.

The problem is that the field names in the report wouldn't match the field names in the cursor. To get round that, you'd use generic field names in the report, such as Field1, Field2, .... In the programmitically-generated SELECT statement, you use the AS clause to give those same names to the fields in the cursor.

There will be issues with fields widths and data types, but these shouldn't be insurmountable.

An alternative would be to use my frxGenerate function to generate the report on the fly, in which case you wouldn't have to worry about the field names. But I know how sophisticated some of your reports are, and I suspect frxGenerate wouldn't give you the formatting and layout you require.

Hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[insania]

Thanks to both Mikes,

Im sure something shall be worked out from the answers you have given.