I'm currently developing an MS Access Data Project (.adp) in MS Access
2002.

One of the reports within the DB uses data that is Dynamic and cannot
be stored on the SQL Server. To resolve this, I have created an
ADODB.Recordset in the reports OPEN event, built the necessary records
inside of it, and then bound the report to this newly created
recordset.

Here's the rub:

It seems that no matter what, it iterates through all of the records
but each record displays the value of the last record. So assuming one
field named rptName (which is my setup) where there are 4 records that
say "Oscar", "Dennis", "John", and "Terrance" respectively the report
would return:

Terrance
Terrance
Terrance
Terrance

Obviously this is sub-optimal.

Anyone have any idea what I'm missing and how I can resolve this?

TIA

-j

The problem is that you are using an Access ADP and still trying to
develop in terms of Access. When using an ADP you aren't really in
Access anymore. You are now in Sql Server country but can still use
VBA. The ADP is only a Front End to Sql Server. You need to think in
terms of stored procedures and Transact Sql.

For your report from the ADP you need to create your recordsource from a
stored procedure. First, create your stored procedure. Run it in Query
Analyzer and see if the resultset is what you want. If yes, then set
the StoreProc as the recordsource for your report object in the Access
ADP.

At the bottom of the property sheet for the ADP Report object is a
textfield for Input Parameters. You can populate this textfield like
this with default parameters:

@UserId='tiger', @Begindate='12/15/07', @EndDate='12/31/07'

And these would be parameters in your stored procedure.

Recordset Objects won't work in an ADP. The sql Server equivalent of a
Recordset object is a Cursor. Cursors are used primarily as an add-hoc
tool in Query Analyzer to examine data SLOWLY. Cursors are slow and
resource intensive.



Rich

*** Sent via Developersdex http://www.developersdex.com ***

Which bares "the rub": The Admins will not allow us to create the
additional Stored Procs - forcing us to utilize this particular type
of solution. Would love to go another direction - but can't [at least
not yet] and I need results within a reasonable time frame.

Playing with a .movefirst and a .movelast during this last so many
minutes has allowed me to control whether the first record or last
record is the record displayed. This - to me - indicates that the
report is not properly moving through the recordset on its own.

Any ideas on how I might be able to properly control that movement
would be appreciated.

Rich P wrote:

If you don't have development rights on the sql server then I would
scrap the ADP solution and use an mdb and ADO to work with the data from
the sql server. Then you can start thinking in Access terms again.

If your employer is bent on the ADP without the flexibility to develop
required procedures on the sql server then your only other option would
be to start playing solitaire.

Rich

*** Sent via Developersdex http://www.developersdex.com ***

This IS possible. The problem can be solved using the FormatCount
parameter in the report's Detail_Format() event, combined with a value
stored somewhere to say if you're on the first record or not. When
FormatCount = 1 you should advance the ADODB.Recordset via code
(unless you're on the first record). This will force the report to
iterate through your recordset - giving you the results you need.

To be complete:

The ADODB.Recordset is first created in the Report_Open() event as a
New ADODB.Recordset. This is a temporary recordset residing in local
memory - and not on the SQL Server. The code for the structure is:

Dim rstAttachments As ADODB.Recordset

Set rstAttachments = New ADODB.Recordset
With rstAttachments
.CursorLocation = adUseClient
.CursorType = adOpenDynamic
.Fields.Append "rptName", adVarChar, 255
.Fields.Append "delete", adBoolean
.Fields.Append "recNo", adInteger
.Fields.Refresh
.Open
End With

The recordset is then populated - in this case using information in a
series of checkboxes in a user form - and then once populated is
assigned to the report's Recordset property. The original recordset -
rstAttachments - is then set to NOTHING, and the report's recordset is
moved to the first record (just to be safe).

Set Me.Recordset = rstAttachments
Set rstAttachments = Nothing

Me.Recordset.MoveFirst

In the ReportHeader_Format() Event the Reports Tag Property is set to
0. This allows me to know when I'm in the Detail_Format() event if I'm
viewing the very first record or not. This is important because I
don't want to advance the cursor if I'm on the first record - only for
the later records do I want to advance it.

Me.Tag = 0

The final bit is in Detail_Format(). Taking my cue from the value of
FormatCount, I move the record pointer ahead one when FormatCount = 1
- EXCEPT when Me.Tag = 0. When Me.Tag = 0 I ignore the record pointer
and set Me.Tag to 1 so that the next time FormatCount = 1 the routine
will work.

If FormatCount = 1 Then
Select Case Me.Tag
Case 0
Me.Tag = 1
Case Else
With Me.Recordset
.Fields("delete") = True
.MoveFirst
.Find ("delete = False")
End With
End Select
End If

Note that in the above routine I used a slightly paranoid approach. I
marked records off as they were formatted and then traveled back to
the first record and searched for the first, unformatted record. I
have no reason to believe a simple .movenext is insufficient - I'm
just paranoid like that. Also, this may not be the best way to go for
a large recordset.

On a final note, I simply close the recordset once I'm done with it
via the Report_Close() event.

With Me.Recordset
.Close
End With

Oko wrote:

On Nov 27, 5:21 pm, Oko <without... (AT) gmail (DOT) com> wrote:
My idea is that you did something wrong. If you post your code I, or
someone else, might even be able to tell you what it is. If we can't,
we will have learned something new from your code. If you don't post
your code, I'll just write you off as the kind of inexperienced newbie
who might accept the rest of the erronoeous and misleading replies you
have received, as valid.
" When using an ADP you aren't really in Access anymore". There's
stupid and then there's this guy who says whatever come into his head;
usually it's wrong!

On Nov 27, 8:30 pm, Oko <without... (AT) gmail (DOT) com> wrote:
I just tried this in Access 2002. It works. Perhaps, there is
something here that will help.

Private Sub Report_Open(Cancel As Integer)
Dim r As ADODB.Recordset
Set r = New ADODB.Recordset
Dim z As Long
With r
.CursorLocation = adUseClient
.CursorType = adOpenStatic
.LockType = adLockBatchOptimistic
.Fields.Append "AccountID", adInteger
.Fields.Append "CommonName", adLongVarChar, 255, adFldIsNullable
.Fields.Append "Valid", adBoolean
.Open
For z = 1 To 3
.AddNew Array(0, 1, 2), Array(z, Chr$(z + 64), CBool(z Mod 2))
Next z
.UpdateBatch
.MoveFirst
End With
Set Me.Recordset = r
End Sub

It shows

1 A check
2 B
3 C check