ansaurus

Question

Form.CurrentRecord=1 and Form.RecordSet.Absoluteposition=-1

Answer 1

A:

You have to place the record pointer on a particular record in the form's Recordset via a MoveFirst or whatever. And the return value appears to be zero-based instead of 1-based.

I can't reproduce the error you're getting returning -1. Are you setting the form's recordset to an ADO recordset? If so, that might explain it -- DAO recordsets never return -1 for any of these values, but I believe that before a .MoveLast an ADO RecordCount returns -1. Perhaps AbsolutePosition does the same in ADO.

What are you trying to accomplish? I don't see any utility in using the form's Recordset object when it's so much easier to assign a recordsource and navigate the RecordsetClone (which is much more closely bound to the form's edit/display buffer than the form's Recordset, particularly when the Recordset has been assigned with an ADO recordset).

David-W-Fenton 2009-05-22 23:46:33

"but I believe that before a .MoveLast an ADO RecordCount returns -1" -- incorrect. Unlike a DAO recordset, the RecordCount property in ADO does not change merely by navigating the EOF because all rows are fetched; even while fetching rows asynchronously, in the _Progess event the RecordCount shows the final value rather than the number of rows fetched so far. Therefore I can't see how AbsolutePosition could fail to work the same way.

onedaywhen 2009-05-26 10:39:44

I can't replicate the reported problem with either the form's .Recordset or the .RecordsetClone. It returns 0 for the first record every time I tested it, so I don't know what the problem. There *is* some circumstance I recall where an ADO recordset's .RecordCount returns -1, but as I don't use ADO often enough to store these things in my brain, I don't recall the exact circumstances.

David-W-Fenton 2009-05-27 03:09:02

RecordCount returns -1 when the property is unsupported e.g. either the provider doesn't support it (not the case for ACE/Jet, of course) or the provider settings do not support it e.g. you are using a forward-only cursor. What I am saying is that navigating the EOF will will never cause the RecordCount to change, whether it is -1 or otherwise. IIRC DAO does't always fetch all rows: sometimes you have to navigate the EOF in order to get the correct RecordCount i.e. RecordCount value can change. In ADO, the RecordCount never changes, even when it is -1 (meaning 'unsupported').

onedaywhen 2009-05-27 10:31:09

It's Jet whose RecordCount to not be accurate as an exact count of records and it's a result of the "Rushmore" technology that MS got with FoxPro and ported to Access. It starts delivering the first records (for DynaSets, not SnapShots) before the whole recordset is loaded. It's eventually accurate (how long it takes depends on how much data and bandwidth), but a .MoveLast forces it to be accurate. Note that a non-empty DAO Recordset will never return a .RecordCount of 0, so you can test .RecordCount<>0 to know if your recordset returns records.

David-W-Fenton 2009-05-27 23:05:55

I take your point but to be clear you are describing Rushmore+DAO behaviour only. Rushmore or no, an ADO recordset's RecordCount always reflects the final amount.

onedaywhen 2009-06-01 10:25:49

Answer 2

A:

If this is ADO, check which OLE DB provider is being used e.g. (guessing)

Debug.Print Form.RecordSet.ActiveConnection.Provider

If by chance it is the 3.51 version, see:

INFO: AbsolutePosition Property with JET Databases in ADO

...if you are using the ACE provider, perhaps it's a regression bug?!

onedaywhen 2009-05-26 10:49:08

ansaurus

tags:

views:

answers:

Form.CurrentRecord=1 and Form.RecordSet.Absoluteposition=-1

related questions