False error “Windows Cannot Find”

Topic

New Reply

Hi, I’ve searched several sites and cannot find a solution, most replies apply to Excel. [/FONT]

I am running XP with Office 07. I created an Access .adp with an SQL backend. The program and data reside on servers in our HQ. [/FONT]

When I open Access, then the database or when I double click on the database through explorer it opens correctly. If I open it with a shortcut or with a link in an Outlook email I get the message: “Windows cannot open [/FONT]\Serverpathdatabase.adp[/FONT]. Make sure you typed the name correctly, the try again. To search for a file, click the Start button, and then click Search.” :unsure: The weird thing is, while the error message is displayed the database opens correctly. [/FONT]

Thanks in advance for your help,[/FONT]
SadieAnn

Reply | Quote

Replies

Are you running the ADP frontend from a network location or from the users local hard drive? The local hard drive is the recommended solution. Your error message suggests you are running it from a network location, and it may be a timing issue. If that is correct, copy the .adp file to your local hard drive and run it from there.

Reply | Quote

Thanks Wendell! :cheers:

This answers my question but unfortunately it does not solve my problem. The boss wants this run off the network. He likes to keep one version of the truth and it makes it easier for the network guys.

You referred to a timing issue; is there a field I can reset somewhere?

Thanks,
SadieAnn

Reply | Quote

Wendel

You suggestion that timing is the problem intrigues me as I get EXACTLY the same error as SadieAnn – it tells me that it cannot find the file (.accdb) but invariably behind the warning the dbase opens perfectly everytime – but, in my case, my database is running off the local machine?

This Access Dbase was originally created in Access 2007 but is now migrated to Access 2010 running on a blindingly fast Windows 7 64bit Ultimate 6 core machine with SSD HD’s (Average Windows score performance 7.7).

I wouldn’t have thought that timing was an issue in my case?

Paul C

Reply | Quote

That really doesn’t have anything to do with the truth – the data is all stored in your SQL Server tables. The idea of putting the ADP on the local hard drive is to prevent you having to load files and the code into the local workstation from the server each time somebody wants to run a specific function. Also, believe it or not, ADP files can go corrupt, and the more users you have hitting the file the greater is the probability of that happening.

That said, putting the files on the local hard drive has its own issues. The biggest issue is to keep the local copy current from a design point of view. The most common approach if you have no more than 5 or 10 users is to use a batch file to copy the latest version to the local hard drive each time the database is opened. In addition, you can have connect string issues in certain network configurations. If those files are located in a different physical location, you almost certainly have a timing issue, and putting a copy on the local hard drive may or may not solve that problem. However moving just the SQL traffic across the WAN will be much more reliable than pulling the ADP elements across each time.

In addition, you should be aware that ADPs are no longer a favored solution – at this point Microsoft has no plans for further enhancement of the ADP approach from what was offered with Access 2003. Thus some of the new controls in 2010 may not work with ADPs. To provide further advice, we would need to know a fair bit more about your network topology, the number of users, and other information about your application.

Reply | Quote

Thanks, I’ll need to discuss this with my boss.

I do have a question about .ADP not being supported in the future. I have been developing with Access for years but this my first experience with Office 07. One of the DBAs converted the database to .ADP so I ran with it. I have another to convert and when I started working with it Access defaulted to an .accdb extension, I assume that is MS’s direction.

Thanks again,
SadieAnn

Reply | Quote

You are correct – the .accdb format uses the ACE engine rather than the JET engine used by .mdb format databases. Unless you need some of the specific new table properties, such as multi-valued fields, we stick with the .mdb format. In that we use an ODBC connection to SQL Server, and only convert things to SQL Server stored procedures or views where there are performance issues that we need to deal with. DBAs are likely to favor the .adp format because that really does convert everything to SQL Server except for forms and reports, but development time using ADPs tends to take about 3 times as long if you start with that approach. You might find this Microsoft article on ADPs interesting – the current view is that ADPs are still supported in Access 2010 as they state it, but that they don’t anticipate enhancing it to support new SQL Server features. Until we find a compelling reason to use ADPs, we are sticking with .mdb formats – for one thing, they work equally well in 2002 and 2003 as they do in 2007 and 2010.

UPDATE: You might find this UtterAccess thread about ADP compatibility and support a useful resource for discussions with your boss. The bottom line is that it looks like ADPs will continue to be supported, but there will be some limits in terms of compatibility with recent versions of SQL Server.

Reply | Quote

Thank you very much, you have been very informative. I’ll check out the links you suggest.

SadieAnn

Reply | Quote

You are correct that timing is probably not the issue in your case. Have you tried creating a full shortcut to the database rather than just using the file name and path? Look at the Access switches that you can use with Access and see if putting the full expression for starting the database resolves the issue. Also does it give you the actually file name, or is it simply “the file cannot be found”?

Reply | Quote

autobackup, what other program is involved when you get the error, also Outlook?

Reply | Quote