Replies

Hey, Preston,
I’m not the original poster, but after receiving a call from someone in the field who is having the same trouble as the original poster, I went searching for the answer — both on Microsoft’s website and here — and I found your answer, tested it out, and — it Works! Thanks for responding on board to the earlier request, I wanted to let you know that someone else found it helpful!
Pat

A real sweet, ripe peach eaten alternately with a dill pickle.
Cottage cheese with several shots of Louisiana hot sauce.
Pat

Well, there is more than one flukey thing, and I just add these for interest.

Don’t spend any time on this, this is mostly just FYI and for me to vent on my perplexed state . As I said, I’ve given myself a safety confirm in the “on-delete” module (that _is_ working!), even though I feel there’s something not so good going on w/ my code, or something else:

First, just the option settings and the setwarnings issue:
I searched the code in the entire database. I don’t have a line of code anywhere that sets warnings either on or off, and the manual options are all checked.
Yesterday I tried to explicitely set warnings on, and I just tried it again, and it made no difference (docmd.setwarnings True).
The two other forms run as expected, bringing up the default Microsoft confirm message, with the exact same code line. All forms are set to “allow” filters, edits, deletions, additions, “Data Entry” = no, Recordset Type = dynaset, and locks = edited record. I don’t open either form w/ any restrictions. I don’t see any differences (except that the two working forms are related, and one is a subform of the other, and the problem form calls an option setting “Behavior Entering Field.”

Secondly,
a.) not only is the expected default Microsoft warning expected w/ all my settings not working, and
b.) the “before delete” getting bypassed (I have a msgbox there), and I have used this event before successfully, but
c.) the msgbox in an on-error code bit that I put in the Delete button “on click” is not firing — _unless_ I put a breakpoint in there and step through it. And there is an error, I find.

Here is the line that triggers the error, that (once again) only displays if I have entered a breakpoint and step through:
docmd.runcommand acCmdDeleteRecord.
The error that I get when I step through the code: 2046: The command or action “DeleteRecord” isn’t available now.”
Additionally, there explanatory statements in that error:
*”You may be in a read only db” — it’s not read-only,
*”(you may be in) “an unconverted db fm earlier version” — it is not,
*”The type of object the action applies to isn’t currently selected or isn’t in active view” — I placed a “docmd.runcommand acCmdSelectRecord” just prior to the delete, but I didn’t think that was necessary, and this line also triggered the same error.

Once again, no answer is necessary, this is all just curious.
thx
Pat

Charlotte,

I just went for a search here because of a flukey thing that’s happening to me, and found the original thread for this message very similar to my experience (only, it was Access 2000) . Like Sarge, I’ve lost my Access confirm in only one of my forms (“Do you really want to delete .. ” etc.) I have all the confirm options in Options turned on. I tried to put a warning in the “BeforeConfirm” event, and, (although Sarge had code in the “AfterDeleteConfirm” event), like Sarge, that code never ran. So, I moved a confirm into the “On Delete” event, and I now have my own programmed confirm, but it’s really bothering me —

This database is small, very simple, and consists of three forms only. One other form as the identical call (docmd.runcommand acCmdDeleteRecord) and immediately pops up with the Access built-in confirm msg, while this one form does not. There are a couple of calls in the problem form, and one of the calls is to an “Application.SetOption “Behavior Entering Field”, 1″ . I commented out that code just for a test, and the behavior difference did not change, and I next compacted the database just in case (with the “Behavior” call still commented out) and the behavior didn’t change.

I’m fixed now using the On Delete event, but, do you have any ideas of what could be the problem? I did a quick look at the KB’s on Microsoft, and found something that seemed to relate to web-based record deletions w/out warnings (Access 2002), but nothing similar to my experience.

Just FYI if you have no answer — basically, I’ve gotten around the problem.

thx
Pat

Er, I should have read your very _first_ post, instead of the last one. I see that you have checked the regional settings. One question out still, though — there is short date, general date, etc. What specific date format are you using (general, short) — and do those settings match what is expected.
thx
Pat

———————– earlier post ————————–
Have you looked at your date settings (international settings) on the individual machines?
It’s a possibility that they are different.
I’ve had this sort of experience with a couple of reports that I’ve created, although we’re supposed to have a single standard for our short date — sometimes, the computer user will go in and change manually.
thx
Pat

> I think the moral of the story is, “don’t expect to recover anything, and you won’t be disappointed!”

Always wise!
thx
Pat W.

Re: data can sometimes be recovered if the database wasn’t closed:
My experience involves an Access97 database, which may be different from the 2000 in what you can recover.
A user (well, actually, the creator of the database) removed an entire field containing data in the design a couple of months ago, and then called me desperately for recovery. There was no backup (had just been created on the network that day). I told her not to do another thing, but to CLOSE it and send me a copy. It was then that I read the recovery code from the Knowledge Base, and realized that it shouldn’t have been closed. I went ahead and opened the database in Qedit — an old text editor — and found samples of data that indicated the type of information that she had deleted — and it was in association w/ the other fields, so I wonder if Access deletes the whole table and re-creates a copy when the design changes? In any event, through lots of tedious work (thankfully, there were less than 200 records and most of them had no entries in that column) I recovered in somewhat messy form, the data that had been lost (at least, I was _told_ that I had found them!). I _thought_ I could see a couple of fixed patterns emerging (fi, characters preceeding the particular column) that could make recovery more automatic — but If this involved a lot of records I would definitely go out an buy a package from someone who had already figured that out, if it were available.
Basically, what I want to say here, is that there is possibly _still_ is a chance for him if the database had already been closed.
thx
Pat Williams

Larry,
… You might want to check the thread “Runtime Compile Error” in this forum, and I am sure there are another couple of threads about this subject but I was not able to find on a quick keyword search. I was also getting similar breakages on simple functions such as left or right (hmm, even though my msg doesn’t seem to say so), because of a reference incompatibility in one of those libraries. Charlotte Explains It All in that thread, so I would recommend reading that. I think I resolved the problem by merely removing the comctl32.ocx library reference — I didn’t need it.
thx
Pat

Charlotte,

Sorry it took so long to get back to you — the msg has been sitting half-finished on my desktop for a few days.

> I’m not sure if you’re talking about Active Desktop, but if by Active Directory console you mean the Windows Explorer

_Probably_ simply the Explorer (or is it “Active Directory” or Explorer _with_ Active Directory? — I hate to expose the holes in my knowledge like this — I’m in “user” mode right now w/ these pieces — just using what I need to know to get around). I have the ability to set/view some network securities for certain folders and files.

> whether you have all that nasty HTML stuff turned on in your explorer windows. I set mine for Classic style
None of that nasty stuff! “Don’t give me beauty, give me speed.”

> 4 minutes is extreme and you really need to talk to your network administrator.

Yes, but I have to tell you — the next day, I “propertied” one over and over again, and it took less than a minute each time. Of course, larger files w/ varying extensions (“sav”, “150”, “old”) popped up immediately, from the same subdirectory on the network. So, — hmmm. I don’t know.

> Keep i mind, though, that the dialog you actually see depends on the file extension that Windows recognizes
It seems to be very consistently _only_ Access databases that have the slow-down — although, as I mentioned just previous to this, it’s not always be excrutiatingly slow — I wonder if Windows is not recognizing the .mdb format on our Win2000 network? Would that be possible?

> In fact, the more you describe your problems, the more network-related they sound. I have no trouble with relinking on any of the Win2k machines I work on. You have something seriously wrong with either your installation of Windows or something very peculiar in your databases.

It is possible that our Windows / network setups are different (we currently have dual login, since we are still moving from our previous network). The databases come from all different backgrounds . I guess what I’ll do is spend a little time documenting the response times, and bring it to the network people. I vary between thinking it’s a network issue and not, because I only see this behavior on Access databases — come to think of it, though, I haven’t run properties on any other MS products like large spreadsheets — focused on Access as I was. hmmm..
Well, thanks for allowing me to vent, and giving me some suggestions. Sorry once again for not responding sooner. I’ll get back to the forum if I can discover anything!

thx
Pat

Wendell,
….. Hello again, and on a similar subject! Remember our talk about Acc97 & Win2000, and my recent msg to the forum, the solution to the problem that Charlotte ID’d. However, remember at that time that you and I felt we had experienced _some_ problem behavior w/ Acc97 (mine is SR-2) and Win2000 (mine is SvcPk 2), while Charlotte had not experienced any problems w/ the combination. I was still having some frustration, and, I returned w/ the express purpose of entering a msg to Charlotte, listing some of the problems I’ve had. First, though, I scanned threads to see if anyone had any problems similar to mine, and found your thread — for a later version of Access, though. Also, my problems may not be related to this current discussion, but I felt that it might perhaps.
…… So the rest of this msg is to Charlotte: Just for starters, Charlotte, I pop up my Active Directory “console” window (uh, I’m a lightweight on our network — if you want more explanation here) and highlight an Access 97, 1.5 + meg database somewhere out on the network, and click on “properties.” It takes a good 4 minutes for the properties to respond. Next, I click on the “securities” tab, which takes another minute to respond. Next, I close properties, rename the .mdb to .mdb.old, and pop up properties, and they pop up lightening fast — and, are lightening fast if I pop up a similar-sized or larger file’s properties. What gives? This happens all over the network — so, you could think the network problem, if there is one, resides locally . However, that wouldn’t explain the lightening speed for objects _not_ named .mdb.
…. Secondly, the experience people have had w/ the 2nd person opening forms, I have had w/ opening properties (I assign securities on some of these things, and, since we are in the process of going over to 2000, I have been doing a lot of this for a while). If I open properties once for an .mdb, it is slow. If I open them again, it is _verrrrry_ slow. If I open them again, they might not respond back for an hour. If someone else opens properties while I’m looking at it, the slowdown in response also occurs. Something is going on besides just loading, linking, locking, and code.
….. Also, linking tables while on Win2000 is excrutiatingly slow just to begin w/. I don’t do a fell-swoop re-link anymore, I link one table, then the next, then the next. Really, though, I don’t link on a Win2000 desktop — I do all my linking on a 95 machine (which, btw, is still pointing to tables on the 2000 network, but the network doesn’t seem to be the issue if your machine is not Win2000.
…… Just thought I’d add my 2 cent-vent, just for you all’s edification, consideration, or mystification. Or, maybe one of you might have an idea — and, yes, it might involve the network, or Active Directory, or _something_ that I am not educated on.
thx
Pat

Charlotte,

> I’m not surprised it failed, I’m surprised you ever got it
> to run. Once you actually generate the SQL, if you don’t
> but brackets around the destination table’s name, the

Thanks for looking at this for me — see my message to Wendell! I don’t know how I missed that the month-day-yr was separated by hyphens instead of underscores, which were present in the working copy (and which I had physically pasted one line below, to better compare if there was any difference in the strings … and the copy that I finally got working didn’t include either dashes _or_ underscores, and my brain was so blown as not to notice that glaring difference, by that time).
I checked what you suggested, and sure enough, putting the brackets around the bld with dashes, handles the problem. _However_ :
I would like to point out that Access help files only mention the need for brackets (that I can find) in the case of names w/ spaces. I see, though, that the query builder grid (if you look at the SQL generated) automatically puts brackets around names that include dashes — which of course, I bypassed when I created it myself.
Thanks for your input! I appreciate this forum so much, and, as I’ve told Wendell, I’ve archived your messages, his, Marks, as well as other people’s. Thanks so much to all you who shape the Lounge!

Pat

Thank you, Wendell, for your words of wisdom. As it turns out, Charlotte was spot-on — the variance was in the dashes, and nothing else! the reason that the name-building code in the one database seemed to run fine, was that it had _underscores_. I had put one line directly below the other, and compared the docmd.sql call section by section, and _still missed that! It must be the eyes and the small font … although, I would have expected that dashes would be okay — see my response to Charlotte. The name-building-code in the successful attempt that I just happened to do on Windows95 is without either dashes _or_ underscores — my only excuse is that my mind must have been thoroughly boggled by that time .

We have installed SR2. We have had some “inflexible” behavior w/ Access97 and Win2k, mostly excrutiatingly sloooooooow relinking of tables, and (for the couple of us that have the ability) excrutiatingly long times in popping up the properties of the database after the 1st or 2nd time (I wonder if there are other issues there other than Access97/Win2k, though). Also, Windows 2k refuses to load a database that exists on a Banyan network drive, but that’s probably not a “flukiness” issue, just one of moving away from backwards-compatibility. We only have a couple of databases still on our Banyan network. It’s a pain, none-the-less.

> On the other hand, we don’t recommend running Access2k on
> a Win95 PC. We’ve seen some strange things happen in that
> environment too. Just an FYI.

Thanks for the information. I’ll store this for future decision-making — I have discouraged us from upgrading to Access2k up ’til now for various reasons (mostly, “if it’s not ‘broke’ , don’t fix it,” and I guess I’m grateful that I did — except for the handful of us w/ Win2k machines where Access2k might have worked better, most are still on 95/98 machines.
Thanks so much for your input, Wendell! I have archived off several of your messages on other issues (as well as several from others). Yours are among the messages that I look forward to reading,
thx
Pat

Geoff,

re: “.. I am analysing NT perfmon data… ” (skip 3 msgs) ” .. it is just that experience shows it contains data values which are not legitimate (eg, CPU utilisation close to 100% ..”

This reply is a year after your original posts — but I was intrigues because, while I’ve been looking for some information on a 100% CPU usage issue I am having, I stumbled across a KB on 100% CPU usage on Microsoft that had “perfmon” in the topic — that, and combined with your CPU comment in a later message, I thought I’d just pass that on to you (fwiw, you may not be dealing w/ this issue any more).

thx
Pat

Hi, Wendell,
Oh, yeah, upgrades are fun!
Thanks for your reply, I tried what you suggested — in a way. I am using Access 97 on a Win 2000 machine, and my system.mdw is in C:WINNTSYSTEM32system.mdw. Anyway, I joined the (still plain vanilla system.mdw, no changes at all) workgroup that I had placed on the network along with the install that I had created earlier (while still under a Win95/98 system), figuring that I would at least be pointing back to the original. I still failed w/ the same error.
It happens just like this w/ more than one database and more than one Win2000 desktop, just to add that it’s not just one particular database or desktop that’s giving the trouble.
And, come to think of it (don’t know why I didn’t think of this first), if I access a database where the (Access 97 db) front end is on c: but which links to a data backend (Access97 db) on a Banyan drive, it works fine — so it probably isn’t the system.mdw.
So, still perplexed, although I could move the databases or split them all, so it’s not an eventual biggie, just an inconvenience and extra work up front, but, still …. it’s annoying.
Anyway, thanks again for the reply, it was worth a shot!
Pat

| I believe your problem stems from not pointing to the
| Access97 System.MDW file for security purposes. Check and
| see if you are pointing to an Access 2000 version of the
| file which by default is in folder
| C:Program FilesMicrosoft OfficeOffice
| Search for another security file to find the Access97 one,
| and then use the Workgroup Administrator to point to that
| file and see if that solves your problem. Aren’t upgrades
| fun? (sigh)
|
| Wendell Bell (gramps)
| Access-Experts.com

I am receiving this error now on those user machines that have been upgraded to Windows 2000 when attempting to access Access97 databases that reside on a Banyan network drive. We are making the move to a Windows 2000 network system, so this is not a big problem, but it is an irritation none-the-less. Does anyone have any ideas as to why this is happening or what can be done to correct it?
thx,
Pat Williams