More Strange Behavior (1 Viewer)

[gakiss2]

Okay. I searched through the forms you provided but didn't find any validation rules other than the >Date() for DueDate in frmDocDetail. I also checked the VBA code but didn't find anything suspicious there either.

Not sure if that's helpful, since you probably knew that already. Next step would be to have the data as well and make the forms function for us. Right now, I just checked them in Design View.

It always helps to have a second pair of eyes on it. This is the backend with a lot of records removed.

What is your opinion on the /decompile thing? Or rewrite it from a blank slate. Sounds scary but probably not nearly as awful as I am imagining it, right ? Its starting to 'feel' unstable but don't know how much of that is my imagination.

 

[gakiss2]

I am Still interested in figuring out what is going on but I have successfully coded around it.
In the after update for DueDate, I am checking the day of week it is. If it is Saturday I am adding two days, If it is Sunday I am adding one day. And as expected my unwanted check for a weekend date never reveals itself.
I have to admit if feels a bit like defeat and surrender but the Db is back up and running.
So please let me know if you find anything on what is going on and how to fix it but the priority has dropped a notch.

 

[Isaac]

can you upload a copy of a db where we can actually reproduce the bug? with the form that disallows the thing you don't want disallowed?

 

[Isaac]

Never mind, I can clearly see the problem.

 

[The_Doc_Man]

Decompile wherever there is code. If the back-end is pure, that is unlikely to need decompilation.

 

[Isaac]

Decompile wherever there is code. If the back-end is pure, that is unlikely to need decompilation.

Note post #24...no need. Just remove the validation rule.

 

[MajP]

I believe I found this issue at least form. There is something seriously wrong with tblDocIssued. I could not link to it. It would always revert to the old link address, even though no error message was found in the link table manager. My guess is that the path could not change and always pointed to the old path. I tried to compact and repair no luck. Decompile is not a possible solution. That has to do with compiled code and no code is in play here. I had to do a make table query to make a new tblDocIssued in order to successfully link.

I would strongly recommend recreating the tblDocIssued. Something is wrong with that table and likely will get corrupted worse.

 

[Isaac]

I was able to download the post 21 database, view the root cause of the problem (the validation rule on Due Date). I linked to the back end database without changing anything. I got the validation rule as expected.

I then edited the back end database to remove the validation rule from Due Date, at which point I saved the table & closed the db.
I then used Linked Table Manager to Refresh the link. The validation rule successfully disappeared from the FE link, no problem.

Remove the validation rule.

 

[MajP]

I was able to download the post 21 database, view the root cause of the problem (the validation rule on Due Date). I linked to the back end database without changing anything. I got the validation rule as expected.

I then edited the back end database to remove the validation rule from Due Date, at which point I saved the table & closed the db.
I then used Linked Table Manager to Refresh the link. The validation rule successfully disappeared from the FE link, no problem.

Remove the validation rule

Regardless. That table is corrupt and likely going to get more corrupted. I could not link to the table downloaded in 21. I tried deleting the link, and relinking. Tried through the link table manager. All other tables linked no problem. The strangest thing was that I should have recieved an alert that the table did not update the link. You might have gotten lucky. Yes remove the validation rule, but that is just a band aid if you can even get there . The OP already pointed out they did that already. The likely reason it "came back" is that it never really linked to the new table with the update. So only appeared as it came back when in fact the old link was not modified.

So I warn you not put any data into this table without rebuilding. The behavior demonstrated is not normal.

1. Create a clean back end
2. import the other backend tables
3. Rebuild the tblDocIssued using a make table query. You may have to save the old primary key in this table as a number field so you can update other foreign keys.
4. Import new tblDocIssued
5. Compact and repair
6. update foreign keys to new primary key in tblDocIssued if necessary
7. Import other objects.
8. Reestablish references.

Nice clean db and you can sleep well at night.

 

[gakiss2]

Never mind, I can clearly see the problem.

View attachment 86968

That is what it looked like before I deleted it. I was surprised to see that it is there for you. I had checked and rechecked that it was gone. I don't have my original 'uploadver' file. I wanted to check it. All I had done though was to zip it up. But that does explain somewhat. It was there the whole time. Just somehow not visible to me when I looked at the design view of the table. Weird but makes some sense. Yup, that is exactly what it looked like before I (tried to ) deleted it.

 

[gakiss2]

I rechecked again. Validation rule is clean as a whistle in the backend and in the linked table. Now its possible I (stupidly) tried to delete it in the linked table first and then deleted it in the Back end table. If my memory works I believe I had done all the data validation stuff before I even split it into front end / back end.

 

[Isaac]

That is what it looked like before I deleted it. I was surprised to see that it is there for you. I had checked and rechecked that it was gone. I don't have my original 'uploadver' file. I wanted to check it. All I had done though was to zip it up. But that does explain somewhat. It was there the whole time. Just somehow not visible to me when I looked at the design view of the table. Weird but makes some sense. Yup, that is exactly what it looked like before I (tried to ) deleted it.

Glad to hear it is working.

I actually give credit to MajP, he was the first to mention possibly a simple confusion/mistake. It happens to everyone! I spend half the day correcting my mistakes, but it's all part of dev.

 

[gakiss2]

OK, so I learned something for sure. I was looking at the validation rule for the Due Date field in the Table Design Mode. I had NOT looked at validation in the Properties for the table. Other than the possibilities that my back end is corrupt, it seems that is it. I'll try it out and report back. for now I have to wait for users to finish up before I can modify the back end table.

 

[Isaac]

OK, so I learned something for sure. I was looking at the validation rule for the Due Date field in the Table Design Mode. I had NOT looked at validation in the Properties for the table. Other than the possibilities that my back end is corrupt, it seems that is it. I'll try it out and report back. for now I have to wait for users to finish up before I can modify the back end table.

Bingo - that's kind of what I was thinking. It was almost an afterthought for me as well to click Properties on the Column itself. I rarely use table constraints other than unique indexes so wasn't totally familiar.