MSDE DB problem

Comments

• Brian Donahue Posts: 6,590 Bronze 1

  April 14, 2006 10:49AM

  Hi Arun,
  
  I think I've been talking to you on email as well. My suspicion is that the database is not set to auto-grow. Either that or your hard disk doesn't have enough free space on it to allow the database to grow by the specified percentage (or megabytes) that is set in the database properties.

  0 · Share on Twitter
• fordc03 Posts: 49 Bronze 2

  June 7, 2006 10:52AM

  Not that this issue is still alive, but...MSDE has a 2GB limit on the Database size. It cannot grow beyond that, and if anything triggers it to go beyond that, then it will fail.

  0 · Share on Twitter
• david connell Redgate › Posts: 172 Silver 1

  June 7, 2006 1:04PM

  Hi Arun,
  Doesn't MSDE have a limit of 2GB?
  check out
  http://msdn2.microsoft.com/en-US/library/ms165672.aspx
  for more information...
  Regards
  David

  0 · Share on Twitter
• ccollins Posts: 64

  June 4, 2007 11:57AM

  We need a property of the data compare engine that will allow us to break the migration sql script up into X or XXX number of rows per batch. We will give of the rollback, (begin commit transaction), functionality, but that is an acceptable trade-off when dealing with updating msde clients.

  0 · Share on Twitter
• richardjm Posts: 598

  June 5, 2007 5:23AM

  We've no plans currently of implementing a feature like that. Perhaps if you created the migration sql on a per table basis each component would be small enough that it would suit your purposes rather than generate the sql for the entire database?
  
  Just a thought

  Richard Mitchell
  Project Manager
  Red Gate Software Ltd

  0 · Share on Twitter
• ccollins Posts: 64

  June 5, 2007 9:11AM

  I changed the routine to create and execute a migration script per table. This works for most cases.
  
  I have to use case scenarios that this does not work:
  @RowCount = 0.
  2) Control data update on a table containing large XML content, (> 700MB and right at 1GB). When inserting 500MB+ of new data or updating the previous 1,000,000 rows . This use case could benefit from a better method of batching than row-by-row.
  
  In both use cases SqlOptions.UseTransactions and/or CanRollBackOnFailure would be set to false. Giving up this feature is acceptable during a release update when proper business continuity processes are in place and disk space is limited or msde limits are approached.

  0 · Share on Twitter