Thanks - your request makes perfect sense - not every user requires SQL or the overhead that goes with it! I see a lot more Carollas in the parking lot than I do Lexus. The broader markey will never let us down!

>Hi Terry,
>
>our model is to develop local and deploy local and c/s, which has been VFP's strength -- with the exception of the SQL limitations. It makes development a a lot faster. So while we could adjust everything we do to move to SQL, we would lose what has been a real strength. We get it working local, run a process that takes maybe an hour (if we've not violated the backend views stuff, and we have the under pretty good control now), and we're running c/s. But everything is built on being local first: we could change it, but it's a good development model.
>
>We've begged for two prior versions to erase that limit; and included in our begging this time the reason the 8192 limit had to be lifted, just for this one purpose.
>
>But thanks for the thought.
>
>Hank
>
>>Could not the SQL for the BIG views be coded as a SQL DB stored procedure?
>>
>>>Ken,
>>>
>>>this is a killer! The new sql makes is possible to create reporting views (in xCase) that will have sql length that will surely outstrip the 8192 limit. But then we won't be able to generate them! We have reporting views that, before we deconstructed them into concatenating views, had 20+ joins, with perhaps 150+ fields (the model has some 300 entities). VFP9 was going to be the way to reunify our views. And keep in mind that xCase aliases views with the name of the relational path, so these added fields typically have aliases that are 20-characters each -- that's 3000 characters right there!
>>>
>>>We don't need 8192 lifted as a limit for command lines: we need the ability to create views that have SQL > 8192. If there is a way to include a function that accepts a string > 8192 and runs the create sql view process from it, it would greatly enhance the value of the product.
>>>
>>>BTW: this is not a last-minute request. I noted in the UT VFP9 wishlist this same issue.
>>>
>>>thanks,
>>>
>>>Hank
>>>
>>>>>as has been noted on some blogs, the 8192-character limit in building SQL Views will limit the ability to implement the (wonderful!) changes to the SQL engine: will some kind of change be coming for that in the final release?
>>>>
>>>>There are no plans to change/increase this limit, so you know.