Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Select Time out?
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00766479
Message ID:
00770323
Vues:
27
Hi Sergey,

I'll gather the info and mail it to you so you can try to reproduce it. I could try the mem functions en I'll try to rename the cursor. The option not to use the UDF will probably not do any good. As I mentioned in the beginning, the query works fine when I delete some records from one of the tables in the select. So if the select takes a little less time (or memory) it works fine again.

>Hi Mark,
>
>You can zip up it and email to me.
>In meantime, you can run more tests.
>1. Add ? SYS(1016), SYS(1011) before and after you run your app to see memory usage
>2. Try to change the name of cursor
>3. Try to run second select w/o UDF
>
>>Hi Sergey,
>>
>>Unfortunately I haven't been able to create a simple scenario to reproduce this behaviour. I do have a difficult one though <g>. I have a application that uses the database and views with the problem. To avoid starting the appliction every time I created a simple test.prg with the select statements from the views. If I start a new instance of Foxpro and try the test prg, everything works fine. If I start a new instance of Foxpro and try the application interactive it fails. After the app has failed the test prg fails too in this same instance of foxpro. So I thought it had something to do with a foxpro setting. I did a "display status" of a fresh Foxpro instance and reset the environment after a fail of the app so the "display status" output matched exactly. I hoped now the test.prg would work again because the environment was like a fresh instance of Fox. Unfortunately the test.prg still failed. If I restart fox and start the test.prg it works fine again with the same data as before.
>>
>>The only differences between the "display status" outputs after a succesfull and failed attempt are shown below. As you can see the only difference is the alias not having the right name in the failed run. The code of my test.prg is shown below that. I'm completely out of ideas. Do you have any? Might it be a setting that is different but doesn't show up on the display status output?
>>
>>I could send you the complete app and test.prg if you're willing to try this over there.
>>
>>succesfull:
>>
>>Select area:  6, Table in Use:
>C:\DOCUME~1\MARKAR~1.001\LOCALS~1\TEMP\JIG82QH7.TMP     (Readonly) Alias:    GEBREC
>>
>>
>>failed:
>>
>>Select area:  6, Table in Use:
>C:\DOCUME~1\MARKAR~1.001\LOCALS~1\TEMP\HRX0CBOG.TMP     (Readonly) Alias:    HRX0CAVN
>>
>>
>>the test code:
>>
>>lnUBN =         423199
>>lnSec = SECONDS()
>>
>>SET PROCEDURE TO 'standaard dierfuncties','standaard functies'
>>
>>Select gb.nRecId, gb.nType, IIf(gb.nType == 4 And gb.nCode == 29, 20, gb.nCode) As nCode ;
>>	From Gebeurtenissen gb ;
>>	Inner Join Dieren dr On dr.cdd204100 == gb.cdd204100 ;
>>	Where dr.ndd200087 == lnUBN;
>>	Order By gb.nRecId ;
>>	Into Cursor GebCodes
>>
>>?"gebCodes", STR(SECONDS()-lnSec,6,2)
>>lnSec = SECONDS()
>>
>>*! Afkalvingen en droogzetten wordt niet gecheckt op aanwezigheid
>>Select gb.nRecId, Max(gb.dModify) As dModify ;
>>	From Gebeurtenissen gb ;
>>	Inner Join GebCodes gc On gc.nRecId == gb.nRecId ;
>>	Inner Join Dieren dr On dr.cdd204100 == gb.cdd204100 ;
>>	Where dr.ndd200087 == lnUBN;
>>	And IIf(gb.nType == 1 And InList(gb.nCode, 1, 5), .T.,
>flAanwezig(gb.cdd204100, gb.ddd201736, lnUBN)) ;
>>	Group By gb.cdd204100, gb.ddd201736, gc.ntype, gc.ncode ;
>>	Order By gb.cdd204100, gb.ddd201736, nVolgNummer ;
>>	into cursor GebRec
>>
>>?"gebRec", STR(SECONDS()-lnSec,6,2)
>>lnSec = SECONDS()
>>return
>>
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform