From: "Antti Kurenniemi" 

I have no knowledge of SQL server at all, but 5% of 18Gb is about
900Megabytes, so increasing the size by 900 Mb in 30 seconds does sound
like it could be the problem - especially if there was a lot of other
things going on (like other users pounding the same database / server)...

I would think a database "file" is not just empty space reserved
from a disk, but it has to have it's own "filesystem" inside, so
creating it would take a while. When you increased the size manually, did
you take note how long it took? Were you the only one using the database at
that point?


Antti Kurenniemi

"Ellen K"  wrote in message
news:509e9e.8a0132{at}harborwebs.com...
> Some of you may remember that I made a recordings database here to hold
calls
> made to our customers.  (I made the back end.)  When I made it I set the
size
> of the primary datafile to 18GB.  It's been running flawlessly for over 10
> months.   This evening the users started having a problem trying to save
the
> recordings to the database.  The failure occurred on the .Execute
statement of
> the Command that calls the stored procedure.  I noticed that the data had
> reached the size allocated for the file.  The file was set to auto-grow
(5%).
> However, since I couldn't find anything else wrong, and since the test
version
> of the database (which only has 15GB of data in an 18GB-dimensioned file)
did
> not exhibit the same behavior, I decided to try increasing the size of the
file
> with an ALTER DATABASE statement.  I increased it to 21GB.  Lo and behold,
the
> problem disappeared.
>
> So now the question is, why wasn't the auto-grow setting honored?
>
> The users were getting an error message that the timeout expired... the
default
> timeout for the ADO Command object is 30 seconds... thinking out loud I'm
> wondering whether maybe the problem could be that SQL Server TRIED to
increase
> the size, but couldn't add 5% of 18GB in 30 seconds, so the timeout
> expired???????
>

--- BBBS/NT v4.01 Flag-5