Re: Internal Limits - Are there any?

Date: Wed, 3 Apr 91 20:18:39 EST From: pitt!uunet.UU.NET!infmx!washington!scottm (A. Scott Myers SSE) Message-Id: <9104040118.AA17981@washington.> To: uunet!investor.pgh.pa.us!rbp@uunet.UU.NET Subject: Re: Internal Limits - Are there any? Sorry. I should have asked if you are using transactions. If you are, then when you do an update, a lock is appropriated for each row that will ultimately be updated. If you are updating for example, 301 rows, and the Unix kernal is configured to allow for only 300 locks, you will encounter an error condition. If you are not using transactions, please disregard my earlier message. I hope this clarifies. Perfectly! Transaction logging is enabled, and that could be the problem. Now that I think about it, we used to have a problem with another script that ran through a very large table every night and removed certain records. It never had to remove more than a relatively few records (less than 50, say) but it wouldn't run with transaction logging. We had to shut it off, remove the records and start it up again. We had thought about turning this off to do the update but doing it in two pieces worked so we didn't have the opportunity. I'll have to explore this in July. Based on what you say, my kernal must allow between 334 and 341 locks, a very peculiar number. I was able to update as many as 334 records but I could not update 342. This seems like an extremely limited approach. What is the sense of having transaction logging if it can't be used when you really need it; ie, on a large transaction?