Search results

ZLS is neither 'correct' nor 'incorrect'. It is a design choice, and one that works well for me - better than nulls. I had those initially, because I agree that nulls are generally the preferred method for such situations, but I abandoned them because of the problems they were causing. If you...

I require a field but let it be empty because that is what works for the data I am dealing with. I could let it be null, but that requires extra work for dealing with nulls, which is what I specifically designed to avoid. I had it that way and was constantly having to add some version of "Or Is...

Yes, I got it the first time. And you're wrong - it does make sense. Saying that it makes no sense when you have not the slightest clue what I am doing with it is what doesn't make sense. I would have expected that you would understand the difference between an empty string and a null. They are...

You don't know how this app works. It does make sense. I initially had it defined as allowing nulls, but that caused a number of problems that this definition fixed. There is no 'underlying problem'. DLookup incorrectly returns a different value than what is actually stored in the table. That...

Yes - here is a DB with a single table with a single record, as I described. There is one small VBA module that looks at that table in various ways, and shows the results.

Ah, yes - I missed that. Point #4.

Others have gone through the workflow with you, so I will confine myself to just answering your original question. You cannot, strictly speaking, disable an item in a ListBox or Combobox, but you can use the AfterUpdate, BeforeUpdate or OnClick events to ignore such a selection. I have a few...

I have a perfectly ordinary DLookup instance locating a record by an autonumber code. The field I want to retrieve is defined as required, empty string allowed. The record in question has exactly that - an empty string. But when I locate the record and request the field with DLookup, it returns...

Oooohhh.. - you mean the first ALTER changes it to a regular number, and the second ALTER changes it back to an autonumber? Now that makes sense. It would explain why I only get to 127, instead of 255 - two changes with each cycle. And why it makes no difference whether I add data or not. And...

I just added this line to the routine, after the second ALTER: .Execute "Insert Into tmp" & x & "AutoID (ZaznamAutoID) Values(1)" No change - if I comment out either one of the ALTER statements, it runs with no problem. When they both execute, it crashes after #127.

Then why does it crash when I execute both?

Yes, I noticed that - I mentioned it in #23. I also realized that I don't really need to reset it to one. I use it in an Order By clause, and all I really care about is the sequence. I suppose I could skip the reset and just let it keep increasing, maybe reset it if it ever gets close to max...

Okay, I created a tiny loop calling that routine. It reliably crashes on the second ALTER, which does the reset. BUT... It DOES NOT crash when I comment out the only first ALTER. It DOES NOT crash when I comment out the only second ALTER. It crashes 100% reliably after 127 iterations when I...

I do not rename the field. I posted the code that does all this in #23. The tables are used in a join, but are not defined as linked via foreign keys.

I wouldn't think so - I don't delete or create any fields in these tables. You did get the error, though? How did you finally do it?

Well, if you can think of something that is simpler AND lets me keep it all in one file AND does not make the user's life any more complicated, I'd love to see it. Sure, but again, that makes the entire setup more complex. They could be copying to a flash drive, and the drive letter could be...

Okay, you've got me - I don't know. I will be digging into this and changing the code to not use autonumber, but I will try to reproduce the problem myself before I dismantle the existing setup - I'm really curious now. Here is the entire routine that bombs: Public Sub ResetTmpTable(ByVal x$)...

I suppose there is always some way for a creative enough user to mess things up. So, you have an FE that checks - what? You put a new FE on the server and at the same time update a version number somewhere in the BE, and the FE check to see if they match? Also a good method. My single-file...

Looking into this some more, it seems that it's not JUST the autonumber. Quoting directly from The Company: learn.microsoft.com/en-us/office/troubleshoot/access/too-many-fields-defined-error "Access also creates a new field (increasing the internal column count by 1) for every field whose...

Well, maybe a reset doesn't create a new field if the autonumber has never been incremented? I don't know - just heard about he problem yesterday morning from the user, and haven't investigated the details myself yet, but that is the first thing that occurs to me - no reset, if the counter has...