Sorry about that, I was channeling my nine-year-old self for a second. Onto the issue at hand. I looked around a little to see if there were any previous posts regarding this issue, but I didn’t find anything, so here it goes. . .
We have recently implemented NAV in our Brazil office, and we are having some frustrating issues that I hope someone here has seen before. All the hardware and database reside in the U.S. and our Brazil employees access the application through Citrix. As we have encountered issues (accounting, tax, etc), our consulting partner has made the necessary object fixes. What has happened, however, is an issue that is fixed and tested one day will reappear the next as if it were never resolved. Our consultants are baffled, as they are making the same changes multiple times. I know that they do much of their testing and developing on their own servers, which are Brazilian (Brazilian version of SQL Server), so I am wondering if there are potential issues of moving objects created on Brazilian localized servers to a U.S. localized server. Has anyone seen this? I am also wondering if anyone has experienced anything like this before.
Here’s a quick look at our setup.
Database: SQL Server 2005, hosted on a dedicated server with mirroring to a second database for failover purposes. Client: NAV client is accessed through Citrix, which is hosted on two, load-balanced 64-bit virtual servers (VMware). NAV: We are running NAV 5.0 with Brazil localizations and no service packs.
I appreciate any thoughts you have. Thanks in advance!
There are probably multiple developers who all have their own local development database, they don’t all update their objects regularly, and they don’t take enough of an effort to make sure that they don’t overwrite other people’s work. In other words, the object management procedures are not enforced, if there are any at all. So say we start with 2 developers. Developer 1 makes a change to an object, and developer 2 does not update his version with that change. Then developer 2 makes another change, and when they import their version into the test database, the change made by developer 1 is lost.
Objects don’t spontaneously revert to old versions of themselves, so there is something going on. In addition to poor object management procedures, maybe someone is sweeping the objects every day and making sure that there are no ‘unauthorized’ objects are in the database. The next thing I’m thinking is that the person that imports the modified objects does it in the wrong database. Get everybody on the phone that has access to the object designer and see if anyone is doing something like that.
With multiple developers it is crucial that everyone strictly follows object management procedures, and that ALL modifications (including new versions of existing modifications) are tagged with a new version number, so that you can see there is a change in the import worksheet. Failure to implement proper object management procedure can be a severe project risk, which happens sometimes.
I agree with almost everything that Daniel says, except… In my experience in a system like this, getting everyone on the same page is impossible. There are two many ownership and ego issues involved. I would feel that the best solution is to only allow ONE PERSON access to import objects into the production database, this way you will have one point at which the error could occur and thus it will be easier to fix.
Details David, that all falls under “implement proper object management procedure” [:D]
I do agree with you though, ONE person should be in charge of object management, and that person’s gate should be at the central development database. All developers have their own local copy that they develop on, and the object guy makes sure whether delivered objects are ready to go into the central development database. From there there should be two more gates, one between central development and central testing, and another one between central testing and finally production.
Years ago I wrote a paper describing my idea of proper object management procedures, I’ll see if I can find it and I’ll post it in the wiki.
Thanks for your responses. Tightening controls is actually the first thing that we did when we started seeing this problem. Hopefully the improved development and change processes will avoid this issue in the future. Thanks for taking the time to share your experience.