Opening Access

[Micron]

Then that seems to rule out any issues that might be related to owner/vs user for the shared folder and the associated permissions since (I presume) you are the one logged in on both pc's. If I have time I'll continue looking later.

EDIT - by chance is there an MDW file associate with this db?

[AccessSHELL]

Yes, I am the one logged on to both PCs. But anyone else who can log on to the other PC will have the DB open properly.

[Micron]

You are quick to respond! I edited my post but I think you missed that. If I research it will raise questions. As long as you're ok with that, it's cool. If I'm being a pest, let me know.

In addition to the edit I made previously, I came across another post and it raised another question. Do you know if anyone else has the db open when you attempt to open it on the problem pc? If so, try opening it when you know no one else has it open.

It's starting to look like a hardware issue, but you've already ruled out changing the graphics card change as a trigger - as long as you had the same card and didn't alter its settings. I also found that someone had this issue and in older versions of Windows you could choose how to open a program wrt to graphics. Access didn't like the accelerated option. As soon as that was changed for Access, problem solved. Unless there was no hardware change for you but a change in settings for the existing card at some point...

[AccessSHELL]

Micron, I am OK with you raising questions. I know you are tying to help me and I appreciate it.

No one else is trying to open the DB at the same time. That situation cannot happen here.
I don't know how to change settings on a graphic card. Even if I did, I would not do that. There are only 2 people here. We don't know how to do that.

[Micron]

Well, it seems that you have a lot of traction over at AWF as well. Unfortunately, with cross posting you often get a lot of repetition, which I don't understand. I guess it's easier to post a question rather than familiarize oneself with a problem by looking at the linked thread. I thought about seeing what could be done with older versions, but I have what A97 on an old laptop, but I don't see that as having much potential. Besides, from what I've digested, it all seems to be about one pc.

When I next refer to "hardware" I'm basing that on the pc and its install of Windows.
What if the other user uses your pc and opens it for a few times? If it doesn't happen then it may not be just a hardware issue, as long as there are enough attempts to gain some confidence that it might be something other than hardware. So if they opened it say 10 times and it never happened is that enough to indicate it may be profile and hardware related (your pc and your Windows install)? Or would that take 25x? If it happened say in 3 attempts, then it must be hardware related, but as I'm suggesting, the OS install is specific to your pc.

Way back I was thinking of a Windows repair on your pc (maybe I suggested it) but I always consider that a last resort. If you are open to using an autoexec macro, it may be possible to run a snippet of code. I'm thinking along the lines of DoCmd that selects an object. That might activate the db window and display it for you. For the other user, it shouldn't make a difference. Or you could experiment with a) a startup form or b) a splash screen to see if either fixes it. I consider these things to be workarounds rather than a fix to the cause of the problem. Sometimes that's the best that can be mustered. I also figure you have the option to click on the Window menu and activate it through that. I have to guess because I can't test that.

[Micron]

Found another possibility - AV. Perhaps the "good" pc has none, or a different version, or a different setting. I don't know (or forgot) what environment you're working in, so AV might not apply. AV should not be scanning mdb files if that is the case.

[Micron]

You didn't answer re the MDW file. If you don't know what that is and you created the db then nothing to check there. IF you didn't create the mdb then you should verify if an mdw file is involved or not. If there is one in the same folder, you probably should mention that at AWF (or wherever there is a user who can run 2003).

[AccessSHELL]

There is only one user on the machine in question. All the DBs were created by me manually. That means, I design the table. Sometimes I enter data manually. Other time my VB6 programs enters or reads the data.

As far as MWD files, the suffix is familiar to me, but I don't remember what it is. When the mdb is open, manually or via VB6 a lock file is created *.ldb.
I don't think I ever heard of an awf file.

[Micron]

AWF is the other forum you posted in. I used to be active there but there are too many $41T disturbers, too much politics and such.
Anyway, what about post 36 here?

MDW is, IIRC, Microsoft Database Workgroup file. It was used to control who could do what but I think it was gone by version 2007. Since you didn't know what it was, there is no chance that it is relevant to your problem.

EDIT
Why is VB6 involved here?

[AccessSHELL]

Most of my databases use VB6. to read or write data. Only 1 DB uses internal forms and VBA. For all other DBs, forms or created in VB6 and possibly filled with data from the DB or from Excel.
I think I am stuck with Office 2003 because VB6 may not interact with Excel, or Word or Access for a newer Office.

[Micron]

While this may not be the cause of your issue, I'd recommend you ditch VB6. I studied it but never coded much in it. It's similar to VB for Office in many ways, and since VB for Access is specifically designed to work with all the Access objects I saw no real benefit in developing in VB6 to use with Access db's. Maybe for connecting to other db apps such as MySql but that's a very remote maybe. I'd still lean towards Access as a front end to connect to such back ends. The design of Access forms is so much simpler than what it takes for VB6, and with all the changes to security that have happened over the years, I can only imagine that deprecated development platforms would not play nicely any more in some cases. Besides, VBA provides a LOT of interoperability between other common office apps such as PPT, Word and Excel, and supports Automation.

So again, likely VB6 is not your issue but I would advise you to look for a more up to date version and build forms/reports in Access. You should be able to find a used copy on Ebay or something, even if it's as old as 2013.

Anyway, what about the AV question?

[AccessSHELL]

Both pcs have the same AV. Too many AVs. The other PC is laptop with an SSD drive. My pc is desktop with the more conventional drive.

I have always had a gut feeling that McAfee was the culprit, but could not easily prove it.

I am not sure this is the forum to discuss McAfee. If a moderator thinks it is appropriate, then I would.

[AccessSHELL]

One of my DB does not use VB6. A long time ago, I wrote a calendar for appointments. The data is stored in Access. I created forms and VBA code. The DB has opened with the lead form displayed. It now does NOt. It acts just like the DBs that for data storage only that are accessed throug VB6.

[Micron]

I never liked McAfee - too controlling. FWIW, you can get a calendar app in Access too (I have a copy).
I don't think there is anything else I can add now, besides disabling AV for a few tests. Hope you get a solution.
Also, I have made several related comments and suggestions about moving on - perhaps think them over after 5 or 6 beers.

[AccessSHELL]

I like to write code. I do it for fun. I'd rather write an app than buy one. I usually write accounting programs which I use for myself. I also write solitaire games (not just with cards, including Tower of Hanoi, High Q ). The writing is more exciting than playing them, and I learn more when writing. Most important - I keep the cobwebs away��