TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ---------------------------------------------------------------------------- Richard, the .MDB file will NEVER be allowed to grow past 1Gig. When that sucker fills up, move it offline, and replace it with a new one and start collecting data again. There's no way around it. As for the "negative" number of records showing up, it's because the log is corrupted on the remote agent. You must delete the records (as you did) to fix the problem. We encounter it from time to time. What version of the agents are you running, 3.2.0? >From http://support.microsoft.com/support/kb/articles/Q115/1/43.asp Microsoft Access 2.0 Databases Attribute Maximum ------------------------------------------------------------------- .MDB file size 1 gigabyte Number of objects in a database 32,768 Number of characters in object names 64 Number of characters in a password 14 Number of characters in a user name or group name 20 Number of concurrent users 255 ..Michael Engle ...Lehman Brothers ....Security Engineering -----Original Message----- From: Richard Sears [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 27, 2000 1:25 PM To: [EMAIL PROTECTED] Subject: Can anyone tell me what it going on with my rsntclientlog.mdb? TO UNSUBSCRIBE: email "unsubscribe issforum" in the body of your message to [EMAIL PROTECTED] Contact [EMAIL PROTECTED] for help with any problems! ---------------------------------------------------------------------------- Back a few weeks ago I posted an issue that I was experiencing with RealSecure. My rsntclientlog.mdb was getting over a Gig and I was having trouble getting the engines to sync with it. The event logs were busting at the seams with DB high watermark reached events. Without going into everything that has transpired over that two or three week period, let me give the gist of the situation. It was suggested, from ISS tech support and others in the [EMAIL PROTECTED] that I consider modifying our policy because it was probably a little on the heavy side, and was logging traffic that it wasn't necessary to monitor. After changing the policy the DB would not sync with one of the engines, it would get a DB sync error - unrecognized packet... To fix this problem I went to the detector and deleted the records in the log. The peculiar part was the number of records was at negative (-25). I'm not sure why it said this (could anyone tell me?) but clearing the records on the detector at that engine made it possible to sync the log. After monitoring the rsntclientlog.mdb size over the next few days, I determined that the policy change had little or no impact on the rate at which it's size increases. Rsntclientlog.mdb grew from a paltry 332 KB to a sizeable 1,048,592 KB in less than two weeks. As its size approached 1,048,592 KB the likelihood of a successful synchronization diminished until it would not sync at all. I compacted rsntclientlog.mdb using ODBC admin but the size did not change. I purged some history from the console log (two weeks worth) but the files size remained at the 1,048,592 KB, Why? One positive that came from deleting some of the history was I could sync without any errors. Can anyone tell me what it going on with my rsntclientlog.mdb? Thanks, Rick
