Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Wed, 29 Apr 2009 09:05:01 +1000, "Arthur Barrett" <arthur.barrett at march-hare.com> wrote: >Bo, > >> This %PREFIX% stuff is presumably replaced by CVSNT with something, >> which in my case turns out to be "CVSNT." > >It's defined in the Audit plugin settings in the control panel on the >server. I guess that it is the "Table prefix" entry you refer to. But in my control panel this is an empty field... >> The result is that new tables are created in the databse with similar >> but different names. I now have duplicates in the database: >> >> dbo.CommitLog AND CVSNT.CommitLog >> dbo.HistoryLog AND CVSNT.HistoryLog >> CVSNT.SchemaVersion >> dbo.SessionLog AND CVSNT.SessionLog >> dbo.TagLog AND CVSNT.TagLog > >It looks like when you upgraded that you used a prefix (CVSNT) when you >did not before (dbo could be the default) or you previously used dbo as >a prefix. See below for more explanation... Does CVSNT force this field to be == Username if it is empty??? Because I have never entered anything there.... > >> The column names are different between the tables too, for instance in >> SessionLog I have Date (dbo) and StartTime (CVSNT) > >Yes that is correct. I thought there was a bug because there was no >rename in the MSSQL upgrade file, but I must have simply misread it. > >> There is now data spread over two sets of tables, not the best >> approach. > >I cannot think of any way that the 'upgrade' scripts can create tables - >my guess is that someone has pressed 'create tables' on the Audit plugin >after setting a new prefix. > >You should be able to fix it using 'select into' from the old table to >the new ones - the upgrade scripts are supposed to upgrade your tables >not create new ones... There will probably be problems doing that since the sessionlog.ID is used as sessionID in the other tables and the SessionLog tables now duplicate this ID value that is supposed to be unique... But I don't really mind this duplication, after all this is just my test server where I did all kinds of checks a few years back but never used for real work... I just wanted to mention it in case people run into problems in production servers. -- /Bo (Bo Berglund, developer in Sweden)