Search results

Just now tried it - it does not. Count is still 163 from RecordCount, 0 from DCount, and this is AFTER completely closing and re-opening Access. Whatever is going on is not just some locally cached value that I accessed too quickly.

I have not run into the -1, but I can understand it in the context of a linked table, as Josef mentioned. It makes no sense in a local table. And some people here DO know why certain features were implemented in specific ways. Some have contacts into MS, or have located documentation that not...

I did read it all. And I repeat, I have found a simple work-around - using DCount. What do you think I missed by your 'reading selectively'?

I don't know what my 'superior thoughts' might be. This is bone-stock Access syntax, and it should do what it says. I'm not trying to solve a problem - I already did that, by switching to DCount. I'm trying to LEARN something here. You just telling me to not do that does not advance my...

Yes, exactly as you write. In the real app, there is a good bit of code between the two commands, but I just now wrote a tiny sub doing the same thing and the result are identical: Sub g() Debug.Print CurrentDb.TableDefs("Prilohy").RecordCount CurrentDb.Execute "Delete * From Prilohy"...

I have two commands, both using CurrentDB. One is an SQL command to do the delete, and further on in the process, another command to retrieve the TableDef's RecordCount property. And this 'ghost' count persists, even through closing and re-opening the DB. Of what I've tried so far, only a C&R...

Yes - I see that it doesn't always work. That was the point of my post. What I don't know is WHY. The code for deletion is an SQL command, issued via Currentdb.Execute "Delete * From..." The count code is what I posted above.

Yes, I know how to do all that. But I don't see why TableDef.RecordCount should be a problem. If the table knows how many records it has, this should provide the proper reply, always. If it does not, what is the point of this even existing?

Nice - thanks for taking the time to do this.

What is special or experimental about this? It looks completely straightforward to me. Is there some mention in BOL or similar that cautions against this syntax?

How did you delete them? Maybe that makes a difference. I need to set up some test cases with different delete methods to investigate this further, but I don't think it should matter. This syntax should always work, I would think. I cannot imagine any scenario where having this wrong count...

I have a development machine with 365, and one of my users has an older one with 2007. Both do it. The specific app that's giving me fits is a monolithic system - the user needs to be able to move it around occasionally, and so the single-file design is best for him. I haven't yet tracked what...

That was the code: CurrentDB.TableDefs("tbl").RecordCount It's not stored in any variable - THIS gives me an outdated count.

I've crashed repeatedly on the following: when I issue an SQL command to empty a table, the command CurrentDB.TableDefs("tbl").RecordCount continues to show the count BEFORE the records were deleted. And they ARE deleted. Opening the table shows it empty, and functions like DCount give the...

Yes - if they don't have focus, you can do anything you want. If they do have focus, you are limited. You can make it disabled (which you could not do in 2007, but you can now). You can NOT make it invisible while it has focus. You must remove focus, by switching focus elsewhere, OR making it...

Well, yes- but at least in the newer versions, that no longer prevents you from removing that focus by disabling it. You CAN disable it, even if it has focus. But I can understand why making it invisible when it has focus throws an error. Having it enabled and having the focus remain on it while...

Did you try disabling it before you make it invisible? It makes a certain amount of sense - having it invisible while still having focus would be a little weird. Maybe the disabling will shift the focus away, and then you can make in invisible.

I do that as well, but this form never closes. There are three in the app, and the ribbon controls select which one is on top, among other tasks, but once opened, they stay that way. The overhead involved in constantly opening and closing would be excessive, and the way the app is designed...

Yeah, sorry - I meant hidden as in behind something else that's already on the form. There is a huge graphic image that is manipulated by the ribbon, so I could just put it under that.

Yes, because most of the distinctions you keep bringing up simply don't exist, or you say that having a universally available option is somehow meaningful, while actual behavior is not. Sorry - you've been very helpful with some things in the past, but what you write on this topic just makes no...