Search results

You probably saw that when you were in a form or query. See the MS support page "You cannot export a report to an Excel format in Access 2007". They offer two workarounds. One is to export from the underlying query, and the second is to export to something else like Word. Neither solution is...

Right. That's what I've got. Something else is going on here, but I don't know what it is.

Nope. That didn't work either. OK. So now I've gone back several previous versions and they all had the same code and they all worked at one time. Could it be something about my installation?

I'm afraid I'm a little rusty with Access, so this may be obvious. I've got a form that has a text box that is intended to show the user what the filter is set to. I set the ControlSource to ="Filter: " & [Filter] but all it returns is #Name? I know it's worked before, so what's up?

I think it's pretty well understood that the Access back-end is designed as a desktop solution but works pretty well for small to medium sized applications. What's still unclear, at least to me, is when or if Access as the front-end ceases to become a viable solution. I'm sure that adding an...

While I agree with your summary of JET's behavior, I see a lot of confusion and misunderstanding among Access developers regarding how JET works, hence my claim of the lack of consensus among even among those who are significantly invested in the technology. While I've got you here, let me add...

Wow! Still no consensus. eh? I got a chuckle out of that because I was asking the same question back in 2001 on the old Compuserve Forum. Basically my question was this: The general consensus was that #2 would run faster because of the index, while the other two would return the entire Clients...

OK. One final thing. I know that one of the limitations of Access and the Jet engine was that it had a certain "file server" approach to things. For example, if your data .mdb was on a server and you ran a query like SELECT * from Employees WHERE Employees.LastName="Jones" the JET engine would...

Bob - First of all let me thank you from the bottom of my heart for your lucid and prompt replies. I'm afraid I have a few more questions though. Let's see if I understand how it all works so far - one fact at a time. Let's say I have an Access front end and an Oracle back end. 1. Typically...

OK. So if I do something like this: DoCmd.RunSQL ("INSERT INTO tblUsers CenterID, WorkerID...") Jet will essentially take my "pure SQL", convert it into something quite similar to the DAO code I could have written and send that to the backend. Is that right? Does it do this regardless of the...

What are the implications of that? In particular, if I am designing an application using Access as the front end but with an as yet unknown DBMS as the back end will I have problems with either DAO or RunSQL? I would think that pure SQL would be the more "open" approach.

After a hiatus of a few years I find myself back writing Access applications, so I need to get caught up a bit. First of all help me out with the whole ADO, DAO RunSQL thing. In the past whenever I needed to do any database operations I almost always used straight SQL with DoCmd.RunSQL, e.g...

Aha, I found it. I needed to do this: Me.txtDate.DefaultValue = "#" & Me.txtDate.Value & "#"I'd taken that approach earlier but I had used + instead of &. Like I said, it's been awhile.

I'm afraid my Access skills have gotten pretty rusty over the past three or four years, so I hope this question isn't too obvious. I have a form with a text box for entering a date on it and I want the last date that the user entered to become the DefaultValue for that text box. Here is the...

I have a process that runs a bunch of Append queries. When Warnings are on you will get a message saying something like "You are about to append X rows? Do you want to continue?" If there is a problem with the append you will get a second message saying "<Your app> can't append all the records...

Hmmm... the DoCmd.GoToControl "subfrmSecondaryVictims" DoCmd.GoToRecord , , acNext works for me. Make sure in your case to replace "subfrmSecondaryVictims" with whatever is the name of your subform control not the name of the control's SourceObject. Bill Norton Austin, TX Bill Norton

Shacket was asking the same thing over here: http://www.access-programmers.co.uk/ubb/Forum4/HTML/003162.html Unfortunately he (she) is still having trouble with it. Bill Norton Austin, TX

For starters you're going to need to store the ready-to-print date in a table somewhere. It might be as simple as a table with only one column and one record: tblShipping - ReadyToPrintDate Then on the OnOpen event of the report do something like this: Dim ldReadyToPrint as Date...

I think you'll find your answer here: http://www.access-programmers.co.uk/ubb/Forum1/HTML/003799.html Bill Norton Austin, TX

OK, I did a little research and found this: http://support.microsoft.com/support/kb/articles/Q92/6/85.ASP?LN=EN-US&SD=gn&FR=0&qry=GoToRecord%20subform&rnk=1&src=DHCS_MSPSS_gn_SRCH&SPR=ACC97 This is VERY misleading. What you need to do is something like this: DoCmd.GoToControl...