Problem with zup File (Time stamp of an object)

unnareli

Hi,

I've just released a new patch to a several of my clients. I deleted a field (lets call it Field 5) from a table that was not being used in any of the forms (card) and never had any data in it. There are now traces of this field being used in code, tableralation, flowfields, any properties etc...
All objects compile fine.

We here at touchstone (C.I) release objects to our clients as not modified, all objects have the Date of the release and the time is set to Midnight (0:00:00). (Like Navision has 12:00:00).

After releasing this patch our users were getting the error "Field 5 does not exist........"

I logged on to the system and everything is fine, so after much testing I found out that if I change the time stamp of the object into something else than Midnight everything works fine. But then changing the time back to midnight they get the problem again.

So the obvious fix is to delete the zup file and that works. However my clients have from 50 - 100 users which of none of them have permission to delete files on the Client. And obviously we can't ask their IT to go to each indiviual client and delete the zup file.

So does anyone have any idea on how I can solve this without deleting the zup file and without changing the time because that is our official release Time Stamp.

Another thing to mention is that we are using V3.70A UK version.

Kindest regards, Unnar

kine

May be it is time to change the officially used time... It seems, that it is not good to use midnight (hour of ghosts :-))

DenSter

Ultimately you're getting the error because you removed the field. You need to put the field back. It isn't being used, so it's not hurting anybody.

unnareli

I must dissagree with adding the field because that defeats the point.

If there are no references to the field surely I shouldn't have to add it.

And again just by changing the time of the object without modifying it it works fine, but again doing that also defeats the point of Navision not updating the zup file properly.

It's the princip of things working like they should do.


EDIT: Sorry should have mentioned that I obviously did this update here in a test system before releasing this to clients. I did this update both on native and SQL and everything works fine here.


reg, Unnar

DenSter

I guess I just don't understand the point of removing a field that is not used, especially a Navision standard field. I would have just left it alone in the first place. This is exactly the kind of trouble you run into when you start messing around with standard Navision.

Obviously, when you removed the field, you did not remove all references. You can use the toolkit to find all these references. You should have a clue of where to look for by what your customer was doing when they got the error.

unnareli

Denster Thanks for your Reply.

Ok. This is not a standard Navision field and not a standard Navision Table. We develope a Wealth management solution for the Offshore industry. So the point of removing a field not used is good practice.

I've been doing this for 8 years so there are no beginners mistake. Developer toolkit can't find any references to this field.

I've exported these object into a text file and the only code references to this field are commented out. (So no problems there).

The user is just opening the card.

Everything compiles properly.

All is fine here at my office. Test system at my clients site is ok but not live system. All objects are exactly the same. Everything was applied exactly the same.

So maybe the question in simple is following

How can a object not work at a client site with time set as 0:00:00 but when changing the time to let say 10:00:00 everything is fine. And then to top things if I change it back to 0:00:00 then they get the problem again.

And before saying not use 0:00:00 just bear in mind that I have used this as an official releases for the last 6 and a half years without any problems what so ever.


So it really is a strange one.

I have tried to delete the forms from the db and re-imported them as text file and then compiled but with no luck.

DenSter I really appriciate your time.

reg, Unnar

Stefan_Saevke

We encountered the very same problem with a an updated custom Report.

Recompile didn't help. After that I changed the Report number from 50005 to 50006 and the Report worked.
Renaming back to 50005 had the same error as before. The only way I got around was to change the Report (I added a comment in Documentaton Trigger ) and to recompile. After that all clients could access the Report.

btw. Some clients could access the report even before. That were those clients that never used the Report before and didn't have a Reference in the ZUP file.

:shock:

Regards Stefan

DenSter

What can I say Unnar... I've seen some pretty weird stuff in Navision development, and this is certainly one of them . I have no explanation why it is happening for this one object only. It just didn't make sense to me to remove a field that isn't used. You said it was field number 5, so that led me to believe it was a standard field.

One explanation that we found is that objects behaved strangely is when we did the development on a SQL database, and the customer ran their database on C/SIDE. For some reason it didn't like that either.

If it is really important for you to have the date that way (to me that is just about the least important, and this whole exercise is a waste of time, but that is personal) I would probably try to rebuild the object from scratch. Maybe you can save it with another number, delete the original, and then save it back to its original number. Export it as text, delete the object, import it back in. Export it as a regular object, delete it and import it back in. Those are things I'd be trying, and I see you've tried some of it as well.

kriki

DenSter wrote:

One explanation that we found is that objects behaved strangely is when we did the development on a SQL database, and the customer ran their database on C/SIDE. For some reason it didn't like that either.

It is always a good idea to develop on the same DB as the customer DB.
This is something I noticed when working with 2.60 when I noticed that the sorting of code-fields changed between Navision and SQL!

DenSter

If it were only a difference in data sorting it wouldn't be so bad, but for some reasons there are also these weird unexplained compilation problems. I haven't seen Unnar's problem, but I can totally see something like that happen in Navision.

unnareli

Hi Guys,

I've finally got something back from Microsoft and they managed to replicate the problem and it also exist in version 4. So it's a bug. And they are going to fix it in version 3.70 and in version 4.

When that is likely to come out as a hotfix I don't know.

But the good news is that they manged to replicate it and they can fix it.

DenSter

Excellent news. Good that you got it to replicate in standard Navision too. Let us know when you get the hotfix so we can ask for it.

unnareli

Hi Denster,

It had to be standard navision bug because I've had this practice for the last 6.5 years and my college has been doing this for the last 10 - 12 years without any problems.

But I will let you know when I get something back from them.

Thanks for your input Denster.


Regards,
Unnar Eliasson

Consultant
Touchstone-Landsteinar
Touchstone-Landsteinar is the trading name of Touchstone (C.I.) Limited, a wholly owned subsidiary of Touchstone Group plc