Replies

Wahooo for “Karen” – her utility worked like a charm… helped me get a real sense of how bass ackwards our shared drive is… time to

OK, I’VE TRIED THE FOLLOWING TO NO AVAIL: CAN YOU SEE WHAT I’M DOING WRONG?

U:SHARED2001 LOBBY REPORTS> TREE/F/A U:SHARED>TREE.TXT
C:>TREE/F/A/ U:SHARED>TREE.TXT

ALSO TRIED IT FROM C/WINDOWS/DESKTOP

Any clue what i’m missing? (the drive i am trying to list is the u:shared drive

Thanks Mark,
I’ve tried several variations and changing the drive also but i only get bad command or file name. i’m using windows 95 the drive is u:shared, i would like to view all of the contents of u:shared. Right now I am at a u prompt U:> where to from here?

Cool. Thanks.

Thank you so much HANS!! the database on the microsoft site gave me the understanding that i needed… I now have my first working option group…. and it actually filters!… But i discovered i have a problem… inner join disease… exacerbated by a bad case of over normalization… I need a

Thanks Hans & Wendell

I went with putting the label on the report header of the subreport… but I’m certain there is a way to make it work from the subreports nodata event… it’s my coding that isn’t right…

as for the option group… i’ll start a new thread… thanks again everyone

hot diggity! worked very well… I adapted it to work with the other value of “will send check” but it doesn’t like the spaces… so a “will*” worked instead.

Legare’s suggestion worked great as well…

hmmm, is there any way to blame the formula wizard for this??? LOL

Thank you for the replies Mark and Wendell – I have checked the references and the user’s machine has DAO 3.51 which is the same reference checked on my machine. I did change the machine from 3.51 to 3.6 as suggested, but to no avail. The error msg generated is the same. Recent changes are as follows: this machine came loaded with Office XP and Windows XP. the office package didn’t include Access at all (any version). our company uses office 97 so we attempted to install office97 from the original Office97 CD but learned that it isn’t that simple. Office XP had to be removed before office97 could be installed. office 97 was loaded onto the machine (which included access). officeXP was also reloaded so both versions of office can be used. Service Packs 1 and 2 were also loaded. the only obstacle in the process was the need to change a font name (hatten.ttf) which caused launch problems. at that point access worked. (for about 3months) Then, last week, the wizards, input masks, etc stopped working in access so the user could not easily create db objects and the error msg in question began also. the machine has been taken down and reloaded with office 97 and xp. this has not resolved the error msg. Another incidental is that we use MSMail for our interoffice mail which WindowsXP does not support. outlook 97 doesn’t work with windowsXP and outlookXP doesn’t support MSMail. Therefore we have Outlook 2000 running as a stand alone program. Now if you can weed through that and have an idea for an avenue to venture down, i’d sure appreciate it.

The two tables from the original post represent the new structure that data has to be incorporated into.

tblLegislators is already filled with data (the most signifcant of which is the LName, FName, and LegID fields).

the LName and FName fields in tblcombinedinfo has identical data to the corresponding fields in tblLegislators.

therefore i need to know how to write an append query that will append the DistAdd1, DistAdd2, DistAdd3, DistAdd4, DistPh, DistFax from tblecombinedinfo to tblLegislatorsDistAdd AND append LegID from tblLegislators to tblLegislatorsDistAdd WHERE tblcombinedinfo AND tblLegislators have both matching FName and LName fields.

OR perhaps, i should just append the address info into tblLegislatorsDistAdd and try a hand at manual reassociation of the addresses.

unfortunately, the table splitter can only work if there wasn’t already data in the destination table – tblLegislators. This table has established relationships with other tables and several junction tables based upon the LegID field that is not included in the tblcombinedinfo. remember that this tblcombindedinfo is data from another database entirely, imported so it can be incorporated into this db that needs the same information, only this “same information” is presented in an entirely different structure. I’m going to play with the splitter some more to see if i can get around it… thanks Bat17

Thanks a million guys! i opted to change it everywhere in the DB and realized that i caused it when i was solving another runtime error in the code that occurred earlier in the procedure when i noticed the misspelling in the sql statement and decided to make the english right and proper.

ok, here’s the file and the low down.

frmoperations is the place to start. there is an unbound combo box that has as its rowsource the commID and commname from tblcommittees. this combo box is the parameter for the CommID field in qryCommLists. qrycommlists is the basis for the report RptCommitteeLists. So frmoperations has to be open and a value selected from the combobox in order to open the report. On rptCommitteeLists, txtspecialty is unbound because the code we’ve been discussing modifies this textbox. the data in txtspecialty has to be displayed concatenated and separated by commas rather than in a list hence the code (happily supplied by a fellow lounger) All the data for that textbox comes from strSQL and that being the case i think i’m missing something major in the code… like the connection between strSQL and strSpecialty??? take a look, tell me what you think.

I removed the lines. This places me right where I started, Run-time error 3061 – too few parameters expected 2. I cleared up the confusion but the syntax is going to kill me!

Thanks Hans and John for the suggestions. the new code is as follows and has new problems. the querydef generates a runtime error 3265 “Item not found in this collection” and breaks at the following line:

Set qdf = db.QueryDefs(strSQL)

I’m beginning to confuse myself , i can’t recall what the heck strSQL does in the first place LOL. Anyway the code is now as follows: I appreciate your help through this one guys.

Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
Dim db As DAO.Database
Dim rst As Recordset
Dim strSQL As String
Dim strSpeciality As String
Dim qdf As QueryDef
Dim blnVisible As Boolean

Set db = CurrentDb

If IsNull(Me.MEMID) Then
Me.txtSpeciality = “”
Exit Sub
End If

blnVisible = (Forms!frmoperations!Combo0.Value = 31 Or Forms!frmoperations!Combo0.Value = 32)
lblCounty.Visible = blnVisible
lblDistrict.Visible = blnVisible
Text46.Visible = blnVisible
Text47.Visible = blnVisible

strSQL = “SELECT jcttblAfftoMem.MEMID, tblAffiliation.Affiliation ” & _
“FROM tblAffiliation INNER JOIN jcttblAfftoMem ON ” & _
“(tblAffiliation.AffiliationID = jcttblAfftoMem.AffiliationID)” & _
“WHERE jcttblAfftoMem.MEMID = ” & Me.MEMID

Set qdf = db.QueryDefs(strSQL)
qdf.Parameters(Me.MEMID) = Reports!rptCommitteeLists!MEMID

Set rst = qdf.OpenRecordset(strSQL)

strSpeciality = “”
If rst.RecordCount 0 Then
rst.MoveFirst
Do While Not rst.EOF
strSpeciality = strSpeciality & rst!Affiliation & “, ”
rst.MoveNext
Loop
strSpeciality = Left(strSpeciality, Len(strSpeciality) – 2)
Me.txtSpeciality = strSpeciality
Else
Me.txtSpeciality = “”
End If

End Sub

– Oh well! I thought you might say that… way too many cells to individually reference… Perhaps another route is to automate the copying of the sheets to a new book and sending it to an email group. (the original/parent files are only updated once per day). That would bypass the entire linking issue. The hitch is that i don’t know how to do it… probably a macro… AND I don’t send the document to everyone, the email simply consists of a file link like what follows and general instructions on opening the file: ty |)