Hi all, When importing objects into a database the users get the message “Another user has changed the definition of the Gen. Journal Line table after the activity was started. Start again.” Has some of you (other) [:o)] geniuses found some good solution to this? We have not the option to do this during the night as we are runnning 24hrs pr. day. As well we need to sleep some nights [:D] Possible, but not good solutions are 1) Ask all users to log off and on. 2) Restart the server to force new login. A bit brutal. 3) Learn the users to live with it and “start again”. (Is this safe? When are we 100% safe we have no COMMIT on the way etc.) 4) Well, don’t change anything… The function I would like is somehow to flush the object cache for all users but I am not even sure it would work. Any ideas? Best regards Gudmundur Petursson
Gudmundur, I don’t think there is a way that you can force the refreshing of the objetct cache on the clients. Maybe somebody will post otherwise. The only advice I can think of is to control the process… identify the sessions that are logged on to the server (File → Database, Sessions tab) at the time you want to do the upload so you can warn them either before or after you do it. Surely every systen has some downtime? what about when your system backups are done? Regards, Chris.
Another option would be to inform the users that e.g. each Friday 17:00-18:00 is reserved for system maintainance. Everybody working in the system during this period is doing so on her own risk and has to expect “strange behaviour” like the above.
Gudmundur, I have to agree with the two previous posts. I can’t hazzard a guess as to how many times the network administrator’s have sent an email around the office, saying the exchange server or the proxy server will be down for an hour at 1:00pm. Heinz’s suggested is good - pre warn users and reserve the time! [;)]
As said before, there are possibilities to avoid this messages and it’s just a matter of defining how you handle this issue with the users. We usually upload our modifications during lunch, as we cannot wait until the end of the week to upload changes, so either early in the morning or late afternoon might work reasonably well aswell. to your point 3)… it is safe, yet you might find some situations where a certain process might need to be repeated because the objects changed in the meantime (e.g. new table definition). Another side effect, especially with reports, is the fact, that the new object won’t be loaded until you refresh the client (new login). This depends of course on the server settings (cache, etc.). Saludos Nils
Hi Gudmundur, basically as with any software project that has ever or will ever exist, you need to properly manage the deployment of new versions of software. In essence, the Error Message you are getting, is just one of the symtoms of the problem, but is not in fact the actual problem. To basically deliver new functionality to users, without them having any knowledge of the fact, is not the way to deliver software, even if it is bug fixes. It is important that the user knows there has been a change, and more importantly, if and how that change affects their normal business process, and/or usage of the system. I suggest that all system changes are clearly documented, and that the delivery of the change is agreed to by all the relevant department heads, prior to delivery. If in fact you are changing software as often as once a week, then you need to look carefully at the original software design to see if it truely matches the companies business requirement. Remember the old addage “Failing to plan is the same as planning to fail”. Now having said all that [;)]… there are times when this is a genuine issue, for instance during the first 14 days after going live, where there was not enough testing, so now you are in bug fiux mode. Well the solution here is not to “flush the cache”, but just set the cache to zero. Then there will not be objects in the cache to flush. Still this must be concidered a short term solution and is basically used instead of testing and training.
Thank you all for your good replies. This confirms we are doing it the best way possible, as you suggested, by reserving time and notifying the users. We are using Hotcopy so there is no downtime there. As to no.3) I can not recommend this. I tested it by simple General journal line and tried to post it after changing the table definition. The line did not post but disappeared! We have not made changes to Codeunit 12 that could explain this. Again thank you all.