Full Version: Run-time error '3021' No Curren Record??
UtterAccess Discussion Forums > Microsoft® Access > Access Reports
techsupport10
Not sure why i am getting this error msg and how to fix it??

I changed the Record Source and now I am getting the error message.

when I just preview the result of the record source I get the data BUT not when trying to run the report.
instead I get this error.


when I go to Debug it takes me to this section of the Detail Format of the Private Sub function:
CODE
    Set db = CurrentDb
    Set rs = db.OpenRecordset(strSQL)
    With rs
        .MoveFirst
        Do Until .EOF


I don't understand it.

hope i've provided enough information to get some help on this.
Larry Larsen
Hi
Try something like:
CODE
    Dim MyDB As Database
    Dim MyRecSet As Recordset
    Dim SQLString As String
    
    SQLString = "SELECT * FROM Categories WHERE CategoryID >= " & Criteria    ' The SQL search string
    Set MyDB = CurrentDb
    Set MyRecSet = MyDB.OpenRecordset(SQLString)    ' Creating a recordset using the SQL string
    While Not MyRecSet.EOF
        Debug.Print MyRecSet!CategoryID & ": " & MyRecSet!CategoryName    ' Looping through the created recordset and outputing value
        MyRecSet.MoveNext
    Wend
    MyRecSet.Close            ' Closing the recordset
    Set MyRecSet = Nothing    ' Eliminating the object variable
    Set MyDB = Nothing        ' Eliminating the other object variable

HTH's
thumbup.gif
mishej
When I look at your code I see the you've made an assumption that the Recordset will contain at least one record. Before you can use the recordset's .MoveFirst method you need to check if the recordset has any records to move to - you might have no records which the would cause the .MoveFirst method to raise an error.

Try this:
CODE
    Set db = CurrentDb
    Set rs = db.OpenRecordset(strSQL)  ' this would be a dynaset type of recordset
    With rs
        If Not .EOF Then
          .MoveFirst
          Do Until .EOF
            ' do stuff here
            .MoveNext
          Loop
       End If
    End With


So you should check for .EOF = True first before trying to use the .MoveFirst method. In any case, the .MoveFirst is probably unnecessary here since you will already be pointed to the first record.
techsupport10
John,
although I am no longer getting the error using your suggestion ... now i am not getting the details at all.
it's not displaying the "stuff" between

Do Until .EOF

and
.MoveNext

Why is not showing my details now?
techsupport10
Hi Larry,
on your suggestion, i am not applying correctly.

CODE
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
    Dim strSQL As String
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim strOptionItem As String
    Dim intY As Integer  'vertical position
    Dim intSpace As Integer 'horizontal space between values
    Dim strOptionCategory As String
    Dim boo12 As Boolean
    Dim boo34 As Boolean
    Dim boo5 As Boolean
    Dim boo6 As Boolean
    boo12 = False
    boo34 = False
    boo5 = False
    boo6 = False

    intY = 570
    intSpace = 70

    strSQL = "SELECT InvoiceNumber, OptionSortOrder, OptionCategory, OptionItems, " & _
        "OptionFormat " & _
        "FROM GuitarDetails INNER JOIN FinishOptions " & _
        "ON GuitarDetails.Option_Item = FinishOptions.OptionItems " & _
        "WHERE InvoiceNumber = '" & Me.InvoiceNumber & "' " & _
        "ORDER BY OptionSortOrder, Option_Item"
        
    Set db = CurrentDb
    Set rs = db.OpenRecordset(strSQL)
    With rs
        .MoveFirst
        Do Until .EOF

            CurrentY = intY
            CurrentX = CurrentX + intSpace
  
          Select Case .Fields("OptionSortOrder")
              Case 1, 2
                Me.CurrentY = 570
                If boo12 = False Then
                   'Me.Print Me.GuitarItem
                   Me.CurrentY = 570
                   Me.CurrentX = 1270
                   boo12 = True
                End If

' and so on until all the Case is defined ...

             End Select

' other stuff here for font formatting ...

            Me.Print strOptionItem
            .MoveNext
        Loop
        .Close
    End With
    Set rs = Nothing
    Set db = Nothing

End Sub
techsupport10
could someone please help me.

i am so close ...

i know it's the .MoveFirst but when applying John's suggestion, the Details section is not coming up.
techsupport10
i am attaching the database.
i put some notes as the property description.
strive4peace
Hi Angela,

I just looked at your database ... before you can design forms and reports, you need to set up the relationships between tables. It is wise to use an Autonumber ID in the parent table and Long Integer IDs to relate records in child tables. Read this:

Access Basics
http://www.utteraccess.com/forums/showflat...;Number=1220772
30-page Word document on Access Basics (for Programming) -- it doesn't cover VBA, but prepares you for it because it covers essentials in Access

It is best to make your report bound to data, not fill it out by looping through a recordset ... the Format event of the detail section will fill just one set of controls anyway so your logic is not right.
techsupport10
Hi Crystal,
thanks for looking ...

not sure what to do then as I got help getting the Detail Format section VBA to do the loop and thought that was the way to do for what I needed.

unless someone can help me redo, i rather keep it in tact and figure out why some records are not showing the details in the Detail section.

please let me know if you can help with that.

Also on the ID, i realize that can help, but in the end I do not see the use for them as the relationship is on Guitar to GuitarItem. that is the "KEY".

I can't redo do to time constraints, rather, again, trying to get help to figure out why some records show the details and some do not. I need all of them to show the details and based on the "match" show Program codes.
techsupport10
Crystal,
also the other problem is that the GuitarHeader table where the GuitarItem resides, it'll take a lot more work to create GuitarID.

See this table is generated from a back office database.
That data table doesn't have an ID to use.

It's just a dump into Access of Guitar invoices only to generate these labels as the back office database can't do nor can it hold these other data like the Program codes, etc ...

so i'm working with data from a system that is not "normalized".

i realize I can have IDs in the FinishOptions and ProgramCodes tables ... but since I can't link an ID from the ProgramCodes table to the GuitarItem as it's link solely on GuitarItem, i'm kind of screwed ...


now, it's easy enough, which I just did, created OptioID in the FinishOptions table (AutoNumber) and in the ProgramCodes table link can now use the OptionID, although I have to do a bit more so the forms can have the description but apply the ID instead ... this part, consider it done.


now what?
strive4peace
Hi Angela,

if you insist on using text fields to relate your data, you have got to reduce the size! Currently, InvoiceNumber, Customer Number, Option_Item, etc ... are all 255 character fields. Long Integers take 4 bytes to store -- text, about a byte per character -- from an efficienty point of view, there is no question and no contest.

I also simply do not understand how your tables relate since you have no defined relationships. Working on reports before structure is sound and relationships are solid is right is like building on sand without a foundation.

"I can't redo do to time constraints"

then the building will fall ... you must set a foundation first. Rather than saying you do not have time to do it right, just try -- you are wasting time with your current design. Sorry to be blunt about this. We are happy to help you, Angela, but we want to teach you to fish, not just give you food ...

~~~

"also the other problem is that the GuitarHeader table where the GuitarItem resides"

you need a table to uniquely identify each Guitar -- that is where GuitarID belongs.

You also need a table for Invoices -- and would use InvoiceID to relate information. Currently, your Guitar Header table defines guitars and invoices -- those are 2 separate entities and each needs their own table.

On structure, I do not want to repeat what I have already written in the Access Basics document. You need to see your data from a different perspective, I know that reading the document will help you do that.
techsupport10
Crystal,
I completely understand re: relationships, etc ...

It will be easy enough to create the GuitarID in a separate Guitar table as the back office system does not have IDs. So i have to create it for this as well.

now on the InvoiceID ... The InvoiceNumber is a generated number from the back office database and is used as the "key" for linking to the Invoice details file, etc ..., I would have to create a table where I add it from the GuitarHeader file to generate the ID each time the data is being downloaded into the GuitarHeader from the back office database.

ok, so do I need to change anything in the functions or buy doing all this and changing the strSQL to use the IDs rather then the actual fields will work?

or simply reducing the field sizes (i just kept the default, 255, but certainly can be reduced).
InvoiceNumber is a 7 digit field
GuitarItem is a 15 digit field

all from the back office db.


thank you!
strive4peace
Hi Angela,

just because you have numbers and codes to link up to another system does not mean they have to be the key fields in Access to relate your tables ... in my opinion, it is better not to be. Mistakes sometimes get made and if the back office number is used all over the place, correcting a typing mistake can be a problem.

Think of it this way: we identify people by their names -- yet a good Access database would not use a person's name to link records (even if they were unique).

"do I need to change anything in the functions"

not sure what you mean by this -- but properly structured, your report would not be using code to show the data.
techsupport10
Hi Crystal,
Ok, I re-did a few things.

please see attached and let me know!


thank you!
techsupport10
oops, it didn't attach the file
techsupport10
The tables are "normalized" and relationships established.
However, i still do not see how this will help having a Guitar table with a GuitarID for this purpose as all is working.
The only thing is writing a query to show the resulted as needed.

Considering that the CodeID is unique for every entry in the ProgramCodes table.

I can't see how that would work whereas going by the Code, where the same Code per Option per Guitar would be the identifier of obtaining the correct Code(s) ...

so I'm not seeing how having IDs will help.


Let me know what i'm missing.

i believe that the result can be achieved with what's available ... I am just stuck on how to write it so the result will so all of the variations as indicated in the document.

1. Codes for Guitars without any Option
2. Codes for Guitars when there is an Option
3. Codes for Guitars when there are multiple Options
4. Codes for Guitars when there are multiple Options of the same Codes

Having a CodeID will not accomplish this. Any other IDs will not help accomplish this that I can tell.

anyway to put it
Codes without any Options – could also have up to 4 Codes
Codes with 1 Option – could also have up to 4 different Codes
Codes with 2 Option combined – could also have up to 4 different Codes
Codes with 3 Option combined – could also have up to 4 different Codes
Codes with 4 Option combined – could also have up to 4 different Codes

The Code must be the same Code for when the Options are to be used as the combination.
strive4peace
Hi Angela,

you need to finish setting up your relationships ... all tables should be on the diagram (even if they have no links so you have a good "snapshot" of your database). Then, you need to define more relationship lines.

also, position the tables so that the table on the left is the "1" side of the relationship and the one on the right is the "many" side ... just as we read -- this really helps see the overall flow of how your data must be created.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.