Yep, it is, the format of the nsturesults table is nasty. Rather then having a different entry for each result it has as many results as it can fit in one entry then moves onto a new entry when it hits the max, all space sperated in the form mapid result mapid result which looks like 50 B 75 7.2 63 B etc. I created a user with read only access to the database for my scripts as im only reading from it (makes sure I cant mess it up). Im just not brave enough to write back to it.
Fair enough. Events are, by comparison, relatively straightforward. Each event has one entry in APPAPPEVENT, and data for each field of each event is stored in APPAPPFIELDS. The only odd behaviour is that there's a lot of duplication of data in the two tables, and also that long comments get split into several entries in APPAPPFIELDS. But it's not terrible.
I can see why you don't want to touch NSTURESULTS!
Because if you stuff it up, it could cost you a lot of money. You may not notice problems at first. You might not even notice them until an update comes along that expected everything to be 'just so'. Then you have to resort to the company for support and they say ... that'll be £1200 a day please.
Originally Posted by MrGravell
Even reading from the database can cause problems. Badly written SQL can be a game of "cripple Mr Database" and it can be easy to miss on a test server where transactional read consistency isn't in the presence of a consistent low level of writes from multiple sessions. Hell, sometimes the poor SQL will be supplied by the MIS developers!
My compromise is to read but never write.