Search results

Have you tried the Jet/ACE-specific DISTINCTROW predicate?

You might want to look into PDFCreator, which is automatable from Access, and which I have clients using in their Access 2003 applications.

It's much simpler to just use: strRsltspn = Me!rsltSpnCheck ...as .Value is the default property of a member of the controls collection on a form.

Since it's a correlated subquery, you can't run it by itself.

Why are you expecting it to be fast?

I never automate Access directly, only using Outlook Redemption, as this avoids all the security prompts. So, no, I don't know why the inspector could not be set. I don't even know what it is!

First off, to get WinXP mode, you didn't need to buy Win7 Ultimate, only Win7 Professional. Second, A97 runs just fine on WinXP. I'm running it on this PC, and until a couple of years ago when I migrated everybody to A2003, had many clients running that configuration. In short, I honestly...

I would never build a production system on to of a database created from one of the Access templates or using the sample databases. Both the templates and the samples that come with Access are filled with WORST PRACTICES in so many ways that it would take less work to start from scratch than it...

I can nowhere find any justification for using ADO at all. If your back end is Jet/ACE, then DAO is the preferred interface. If, however, your back end is SQL Server, you really want to use SCOPE_IDENTITY() instead of @@IDENTITY, since an insert that has triggers attached could lead to an...

In regard to the AfterUpdate thing, I dissent from the advice you've been given. I like having ENTER execute the search. That's the way SUBMIT works in an HTML form on a web page, and I think consistency with the way the web works is a good thing. I also will often add a FIND command button...

I can't say I've been following this thread closely, but I just want to say that I *never* edit the underlying recordset of a form. I don't see the point! Just edit the form. The main reason I wouldn't do it is because I don't have any control of the relationships between the form's recordset...

I'm not a user of Sharepoint, but it seems to me the difference would be between linking to a Sharepoint list, and linking to a database stored in Sharepoint. But I'm foggy on the differences!

The correct DAO reference for A2003 is DAO 3.6. Looks like you may have run multiple versions of Access, which changes the registration, and can cause A2003 to hook up with the wrong Access components.

That's a significant missing reference. If it's an MDB, that's the wrong reference (it should be DAO 3.6). But if it's an ACCDB and it's A2007, then you need to re-register that DLL. One way to do this is to manually search for it with the browse button found in the references dialog and to...

OLE Automation is probably not necessary. If you examine its contents in the Object Browser, you'll see that it offers virtually nothing of any use. I really can't imagine why MS thought it was wise to make it a default reference.

Java and JavaScript have virtually nothing to do with each other, other than the first 4 letters of the name. And, of course, they have nothing at all to do with programming in Access.

A form's .RecordsetClone property returns a DAO recordset, so you have to use FindFirst instead of Find (Find exists only in ADO recordsets). There is very seldom any justification at all for using ADO in Access. Is there some compelling reason why you're using it?

Before the VBE, Access had its own code editor. The VBE was not much of an advance for Access users. To me, the motivation for making Access's VBA behave like the other VBA implementations in Office (e.g., defaulting to OMIT Option Explicit) had nothing to do with what was best for Access...

The VBE was introduced in Access 2000. VBA was introduced in Access 95.