FWD » Core Development » Database

for each stat1:
   delete stat1.
end.

define buffer bStat2 for stat1.

create stat1.
stat1.f1 = "abc".
stat1.f2 = "bcd".
stat1.f3 = 10.
stat1.f4 = 4.
stat1.f6 = 'qwe'.                                                                        

define var hq as handle.
create query hq.
hq:set-buffers(buffer bStat2:handle).
hq:query-prepare("for each bStat2 where bStat2.f1 = 'abc' and bStat2.f2 = 'bcd' and bStat2.f3 = 10 and bStat2.f4 = 5").
hq:query-open().
hq:get-last().
message hq:index-information().
message avail(bStat2).

And the follwoing schema definition file:

  MAX-WIDTH 16
  ORDER 20

ADD FIELD "f3" OF "stat1" AS integer 
  FORMAT "->,>>>,>>9" 
  INITIAL "0" 
  POSITION 4
  MAX-WIDTH 4
  ORDER 30

ADD FIELD "f4" OF "stat1" AS integer 
  FORMAT "->,>>>,>>9" 
  INITIAL "0" 
  POSITION 5
  MAX-WIDTH 4
  ORDER 40

ADD FIELD "f5" OF "stat1" AS integer 
  FORMAT "->,>>>,>>9" 
  INITIAL "9" 
  POSITION 6
  MAX-WIDTH 4
  ORDER 50

ADD FIELD "f6" OF "stat1" AS character 
  FORMAT "x(8)" 
  INITIAL "" 
  POSITION 7
  MAX-WIDTH 16
  ORDER 60

ADD INDEX "idx1" ON "stat1" 
  AREA "Schema Area" 
  UNIQUE
  PRIMARY
  INDEX-FIELD "f1" ASCENDING 
  INDEX-FIELD "f2" ASCENDING 
  INDEX-FIELD "f3" ASCENDING 
  INDEX-FIELD "f4" ASCENDING 
  INDEX-FIELD "f5" ASCENDING 

ADD INDEX "idx2" ON "stat1" 
  AREA "Schema Area" 
  INDEX-FIELD "f1" ASCENDING 
  INDEX-FIELD "f2" ASCENDING 
  INDEX-FIELD "f3" ASCENDING 

As you can see in my example I create a stat1 record and fully update idx2. In the hq I search for the record using f1, f2, f3, f4 fields in the where clause. In 4gl and OE, index selected for search will be idx1. So no record will be found neither in primary nor dirty database. Not that if search is preformed only on f1, f2, f3 fields, the newly created record uncommitted record will be found in bStat3.

However there are some tests in customer application that has the same scenario, and it relies on actually finding of the record in bStat1 buffer.

This issue can also be rejected, as it refers to a unit test rejected from customer application.

Eduard Soltan wrote:

This issue can also be rejected, as it refers to a unit test rejected from customer application.

This is a real problem in FWD, right? Then lets keep it open.