On Monday, March 12, 2012 01:04:08 PM Paul McNett wrote: > If you don't think this is horrible, I want to hear why: > > dabo/dabo/db/dCursorMixin.py > 2072 def moveToPK(self, pk): > 2073 """ > 2074 Find the record with the passed primary key, and make it active. > 2075 > 2076 If the record is not found, the position is set to the first > record. 2077 """ > 2078 row, rec = self._getRecordByPk(pk, raiseRowNotFound=False) > 2079 if row is None: > 2080 row = 0 > 2081 self.RowNumber = row > > Why should we implicitly move the record pointer if the pk doesn't exist? > Why not keep it wherever it happens to be? Why not propagate the exception? > What if RowCount==0? > > It just seems dangerous for calling code to ask the system to move to the > record with the passed pk, and then move it to a different pk instead. > > This is called from dBizobj in a few places, via biz._positionUsingPK(). I > see there are a handful of functions in dCursor and dBizobj that do this in > different ways. To be safe in the code I'm writing I'm just going to use: > > if not biz.locate(self.getPK(), self.KeyField): > # raise error or ignore > > To be fair, while dCursor.moveToPK() has been refactored over the years, the > behavior has been there since the earliest days. > > Paul
I'm sick as hell but I recall that VFP did that. If it did not find the record it went to the "top". Johnf _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/1403815.Jm4sAeyN1a@linux-12
