Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP9 - SQL Too Complex???
Message
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Environment versions
Visual FoxPro:
VFP 9
OS:
Windows XP SP2
Network:
Windows 2003 Server
Database:
Visual FoxPro
Miscellaneous
Thread ID:
00988402
Message ID:
01003354
Views:
43
Tonia,

I haven't heard anything new. I thought the MS folks who responded to this thread had said they would get back to us.

I did come up with a work around. I leave the view out of the DE and open it in the form.init() with a bogus parameter that I know will return zero records. From here on out it is available with no data loaded into it, just like it should have been if it had been opened with NODATA clause.

HTH,

Larry


>I was just wondering if a fix for this problem is available yet.
>
>I too was upgrading a VFP7 app to VFP9 and ran into the same error with a few views I have on very large tables.
>The SQL select command works just fine by itself, and I can open the view and it will perform the query, but I can't open the view NODATA and I can't create the view.
>
>I can provide the specifics of the tables if you want - but I figured that probably wasn't necessary because the problem is known and is being looked into.
>
>
>>FWIW, I just ran into the same error upgrading an app from VFP7 to VFP9. The view was working fine with small practice tables in VFP9, but failed with full production tables.
>>
>>Here is the view:
>>
>>
>>SELECT Dtpaeve.*, Dtpaehx.ehx_id, Dtpaehx.run_id, Dtpaehx.line_id,;
>>  Dtpaehx.dphid, Dtpaehx.referral, Dtpaehx.pdisc, Dtpaehx.bal,;
>>  Dtpaehx.dph_form, Dtpaehx.dph_icat, Dtpaehx.insamt, Dtpaehx.partins,;
>>  Dtpaehx.partdph, Dtpaehx.dph_serv, Dtpaehx.rdenial, Dtpaehx.ndenial,;
>>  Dtpaehx.tppcode, Dtpaehx.primary, Dtpaehx.dmacode, Dtpaehx.waiverno,;
>>  Dtpaehx.waiver, Dtpaehx.auth, Dtpaehx.cov_no, Dtpaehx.flag,;
>>  Dtpaehx.line_statu, Dtpaehx.claim_stat, Dtpaehx.claim_err, Dtpaehx.pv,;
>>  Dtpaehx.billing_tp, Dtpaehx.billing_dp, Dtpaehx.bdisc, Dtpaehx.bplace,;
>>  Dtpaehx.code, Dtpaehx.modifier, Dtpaehx.eid;
>> FROM ;
>>     dtpadata!dtpaeve ;
>>    LEFT OUTER JOIN dtpadata!dtpaehx ;
>>   ON  Dtpaeve.eid = Dtpaehx.eid;
>> WHERE ( (  Dtpaeve.cid = ( ?pcCid );
>>   AND  Dtpaeve.btype = ( ?pcBtype ) );
>>   AND  Dtpaeve.serv = ( ?pcServ ) );
>>   AND  Dtpaeve.sdate = ( ?pdSdate );
>> ORDER BY Dtpaeve.eid, Dtpaehx.run_id, Dtpaehx.line_id
>>
>> * DBSETPROPs for making it all updatable not shown
>>
>>
>>
>>This view fails even when called with NoDataOnLoad = .t..
>>
>>Table size makes a critical difference. It fails with the following record counts:
>> dtpaeve: 453000
>> dtpaehx: 639000
>>
>>But works when tables are trimmed roughly in half:
>> dtpaeve: 260000
>> dtpaehx: 331000
>>
>>Using the original large tables, I tried removing all dtpaeve records that lacked at least one matched dtpaehx record, but this made no difference.
>>
>>In BeforeOpenTables, I tried setting enginebehavior to 70 or 80 with no benefit. I also tried some other memory tricks, like sys(3050,20000000) and purge memory SYS(1104) also with no benefit.
>>
>>Looking forward to a work around or bug fix...
Larry Tucker
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform