[Nav-users] Editdb error

-- Kristian >From roar.pettersen at uib.no Mon Jul 3 15:45:17 2006 From: roar.pettersen at uib.no (Roar Pettersen) Date: Mon Jul 3 14:45:22 2006 Subject: [Nav-users] Editdb error In-Reply-To: 8A65B72C71E7484FBE1862045AAC5A8FB73D20@embla.ansatt.hint.no References: 8A65B72C71E7484FBE1862045AAC5A8FB73D20@embla.ansatt.hint.no Message-ID: Pine.SOC.4.64.0607031442450.1934@alf.uib.no Hello ! > Can anyone tell me how to solve this problem? I had exacly the same problem. :-) You have a missmatch in the pysnmp library when you downgraded from pysnmp-3.3.5 to 2.0.8. My solution was to delete /usr/local/lib/python2.4/site-packages/pysnmp/ and install the pysnmp-2.0.8 again. -- Med vennlig hilsen / Regards; Roar Pettersen Universitetet i Bergen - The University of Bergen Nygardsgt. 5 - N-5020 BERGEN - Norway Tlf: +47 55 58 40 55 VIP: 81503 fax: +47 55 58 40 70 roar.pettersen@it.uib.no - IT-Avd, UiB - http://www.uib.no >From morten.vold at uninett.no Mon Jul 3 15:51:23 2006 From: morten.vold at uninett.no (Morten Vold) Date: Mon Jul 3 14:51:33 2006 Subject: [Nav-users] Announcement: NAV 3.1.0 is out In-Reply-To: b4c110fd0607030526s6ad2e098pacb80842a69cbed0@mail.gmail.com References: 8EEE7738AEDF6947B3E5508A0244D1C2A36A31@stam.himolde.no 44A8D9E2.6070700@uninett.no b4c110fd0607030526s6ad2e098pacb80842a69cbed0@mail.gmail.com Message-ID: 44A912CB.1050904@uninett.no Kristian Eide wrote: > NAV really needs to get a proper version system for its schema > changes or it will be very hard to manage such changes in any > reasonable way (manually creating sql patch scripts is not the way to > go). Interesting observation, Kristian, but your advice isn't very helpful without any examples or concrete ideas. What, in your opinion, is a "proper version system for schema changes"? My take on this is that schema changes are relatively few and far apart in NAV today. Therefore I don't see the need to invest a lot of time into devising some elaborate system to avoid having to manually write sql patch scripts. My suggestions is rather to implement a project policy to commit patch scripts along with any schema alterations. That way, a poor release coordinator (me) won't have to piece together every schema change that took place since the last release, and produce a whopping mishmash of hopefully consistent SQL upgrade statements on each release. Also, this should solve the problem for the few who might be using bleeding edge code from trunk at all times. They might not all be SQL wizards, able to analyze the changes and whip up their own SQL statements to change the schema, but each revision that updates the schema will come with an up-to-date upgrade script. We've never claimed that tracking the development trunk should be a piece-of-cake, though. -- mvh Morten Vold UNINETT