Hi, thanks for your response. We did increase this but it is still crashing. We have tried a number of other things. First we tried putting this on a newer kernel running 2.6 (originally was on redhat 9 2.4 kernel). Then when we went to restore the database, again a signal 11 occurred.
Then we decided to restore on a windows machine. Unfortunately we are using win2k and the maxdb odbc driver does not install correctly on it (it doesn't show up in the lits of odbc drivers when after it's installed), so we had to use an odbc-odbc bridge to an XP machine that does work. This caused some memory violation issues so we couldn't do that either. Have come to the conclusion that we need to upgrade the MaxDB software on our current system. It's running better than what it is (doesn't crash every five minutes now). We are running only 7.5.00.05, and there is a much later 7.5 out which we will install. Apparently if you set the MaxDB param HASHED_RULESET to NO, it's supposed to fix the problem. But when we do a param_getvalue of this key, it doesn't exist. It may not even exist until version 7.6. Anyway I think an upgrade is in order, and that's all we can think of that may solve our problem. Auer, Wolfgang wrote: > Hi, > > please increase the parameter MAXUSERTASKS of the database. > If the problem remains you should check if your triggers do a recursive call > or call other triggers. > > regards > Wolfgang > > > Wolfgang Auer > SAP AG > > -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
