Fastest way to delete records
in [Visual Objects]
|
From: Martin on 2 Feb 2010 10:31 I need to trim a file a lot as quickly as possible of certain records. File is roughly 6GB Production build is 2.7, Server is ADS 7.1, going to 9 next week. Testing with 2.8 and ADS 8.1, 4% on my PC and 15% on the "server". This is the current code and does about 750 records a second for delete. SELF:dbBarList:SetOrder(3) SELF:dbBarList:Seek('19900101',TRUE) SELF:dbBarList:Delete(,{||_FIELD->PL_PDate <= dClear}) SELF:dbBarList:Pack() Can anyone think of a way of speeding this up? (Not including my favourite of using a different NOS) What is the RDD doing via ADS? Thanks Martin
From: dlzc on 2 Feb 2010 10:41 Dear Martin: On Feb 2, 8:23 am, "Martin" <s...(a)spam.spam> wrote: > I need to trim a file a lot as quickly as > possible of certain records. > > File is roughly 6GB > > Production build is 2.7, Server is ADS 7.1, > going to 9 next week. > > Testing with 2.8 and ADS 8.1, 4% on my PC > and 15% on the "server". > > This is the current code and does about 750 > records a second for delete. > > SELF:dbBarList:SetOrder(3) > SELF:dbBarList:Seek('19900101',TRUE) > SELF:dbBarList:Delete(,{||_FIELD->PL_PDate <= dClear}) > SELF:dbBarList:Pack() > > Can anyone think of a way of speeding this up? > (Not including my favourite of using a > different NOS) Why not just copy the records where '19900101' =/= TRUE to a new database, delete the old, and rename? Or, if you like to live very dangerously, open the file with two aliases. In one (INVALID) seek to first match. In the other start at end-of-file (VALID) and step-back for "first" non-match. Copy field contents of record from VALID to INVALID, and repeat seek-and-step- back until EOF in INVALID. Mark all records in VALID higher than the current record position as deleted, then PACK. David A. Smith
From: John Martens on 2 Feb 2010 10:44 Martin, I'm not an expert on ADS at all but i my opinion the pack would take the largest amount of time (and needs exclusive acces to the file). I have a data-base where I did a lot of append and delete and then pack. I now blank the record, then delete and re-used this blank record (if there are) instead of apending a new one. In this way you avoid the packing which will take a lot of time on a 6GB file. John Op 2-2-2010 16:31, Martin schreef: > I need to trim a file a lot as quickly as possible of certain records. > > File is roughly 6GB > > Production build is 2.7, Server is ADS 7.1, going to 9 next week. > > Testing with 2.8 and ADS 8.1, 4% on my PC and 15% on the "server". > > This is the current code and does about 750 records a second for delete. > > SELF:dbBarList:SetOrder(3) > SELF:dbBarList:Seek('19900101',TRUE) > SELF:dbBarList:Delete(,{||_FIELD->PL_PDate<= dClear}) > SELF:dbBarList:Pack() > > Can anyone think of a way of speeding this up? (Not including my favourite > of using a different NOS) > > What is the RDD doing via ADS? > > Thanks > > Martin > > >
From: Martin on 2 Feb 2010 10:53 Pack is quicker - it took about 10 minutes including a reindex Recycling is there but I want to get the file a LOT smaller. "John Martens" <adsl672100(a)tiscali.nl> wrote in message news:4b684850$0$28158$5fc3050(a)news.tiscali.nl... > Martin, > > I'm not an expert on ADS at all but i my opinion the pack would take the > largest amount of time (and needs exclusive acces to the file). > I have a data-base where I did a lot of append and delete and then pack. > > I now blank the record, then delete and re-used this blank record (if > there are) instead of apending a new one. In this way you avoid the > packing which will take a lot of time on a 6GB file. > > John > > > Op 2-2-2010 16:31, Martin schreef: >> I need to trim a file a lot as quickly as possible of certain records. >> >> File is roughly 6GB >> >> Production build is 2.7, Server is ADS 7.1, going to 9 next week. >> >> Testing with 2.8 and ADS 8.1, 4% on my PC and 15% on the "server". >> >> This is the current code and does about 750 records a second for delete. >> >> SELF:dbBarList:SetOrder(3) >> SELF:dbBarList:Seek('19900101',TRUE) >> SELF:dbBarList:Delete(,{||_FIELD->PL_PDate<= dClear}) >> SELF:dbBarList:Pack() >> >> Can anyone think of a way of speeding this up? (Not including my >> favourite >> of using a different NOS) >> >> What is the RDD doing via ADS? >> >> Thanks >> >> Martin >> >> >>
From: John Martens on 2 Feb 2010 11:09 Why reindex ? I assume that ADS updates the index when a record is deleted ? You could also do a pack only once a day. John Op 2-2-2010 16:53, Martin schreef: > Pack is quicker - it took about 10 minutes including a reindex > > Recycling is there but I want to get the file a LOT smaller. > > > "John Martens"<adsl672100(a)tiscali.nl> wrote in message > news:4b684850$0$28158$5fc3050(a)news.tiscali.nl... >> Martin, >> >> I'm not an expert on ADS at all but i my opinion the pack would take the >> largest amount of time (and needs exclusive acces to the file). >> I have a data-base where I did a lot of append and delete and then pack. >> >> I now blank the record, then delete and re-used this blank record (if >> there are) instead of apending a new one. In this way you avoid the >> packing which will take a lot of time on a 6GB file. >> >> John >> >> >> Op 2-2-2010 16:31, Martin schreef: >>> I need to trim a file a lot as quickly as possible of certain records. >>> >>> File is roughly 6GB >>> >>> Production build is 2.7, Server is ADS 7.1, going to 9 next week. >>> >>> Testing with 2.8 and ADS 8.1, 4% on my PC and 15% on the "server". >>> >>> This is the current code and does about 750 records a second for delete. >>> >>> SELF:dbBarList:SetOrder(3) >>> SELF:dbBarList:Seek('19900101',TRUE) >>> SELF:dbBarList:Delete(,{||_FIELD->PL_PDate<= dClear}) >>> SELF:dbBarList:Pack() >>> >>> Can anyone think of a way of speeding this up? (Not including my >>> favourite >>> of using a different NOS) >>> >>> What is the RDD doing via ADS? >>> >>> Thanks >>> >>> Martin >>> >>> >>> > >
|
Next
|
Last
Pages: 1 2 3 4 5 6 7 Prev: Quickest instring test Next: VO2Ado ( For Robert o other users )and policies for upgrade.. |