My Assistant
|
|
Sep 28 2007, 06:54 PM
Post
#1
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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. |
|
|
|
![]() |
Sep 29 2007, 01:24 AM
Post
#2
|
|
|
UA Editor + Utterly Certified Posts: 22,722 From: Melton Mowbray,Leicestershire (U.K) |
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 (IMG:http://www.utteraccess.com/forum/style_emoticons/default/thumbup.gif) |
|
|
|
Sep 29 2007, 01:45 AM
Post
#3
|
|
|
Retired Moderator Posts: 11,289 From: Milwaukee, WI |
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. |
|
|
|
Sep 29 2007, 11:43 AM
Post
#4
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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? |
|
|
|
Sep 29 2007, 11:58 AM
Post
#5
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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 |
|
|
|
Oct 1 2007, 02:52 PM
Post
#6
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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. |
|
|
|
Oct 1 2007, 06:23 PM
Post
#7
|
|
|
UtterAccess Addict Posts: 232 From: United States |
i am attaching the database.
i put some notes as the property description.
Attached File(s)
|
|
|
|
Oct 2 2007, 01:50 PM
Post
#8
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
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. |
|
|
|
Oct 2 2007, 01:59 PM
Post
#9
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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. |
|
|
|
Oct 2 2007, 02:12 PM
Post
#10
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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? |
|
|
|
Oct 2 2007, 02:22 PM
Post
#11
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
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. |
|
|
|
Oct 2 2007, 02:39 PM
Post
#12
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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! |
|
|
|
Oct 2 2007, 04:29 PM
Post
#13
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
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. |
|
|
|
Oct 2 2007, 05:45 PM
Post
#14
|
|
|
UtterAccess Addict Posts: 232 From: United States |
Hi Crystal,
Ok, I re-did a few things. please see attached and let me know! thank you! |
|
|
|
Oct 2 2007, 06:29 PM
Post
#15
|
|
|
UtterAccess Addict Posts: 232 From: United States |
oops, it didn't attach the file
Attached File(s)
|
|
|
|
Oct 2 2007, 09:34 PM
Post
#16
|
|
|
UtterAccess Addict Posts: 232 From: United States |
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. |
|
|
|
Oct 2 2007, 11:19 PM
Post
#17
|
|
|
UtterAccess VIP Posts: 20,187 From: Colorado |
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. |
|
|
|
![]() ![]() |
|
Go to Top · Lo-Fi Version | Time is now: 21st May 2013 - 07:47 AM |