October 15, 2004 at 2:33 pm
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com
November 1, 2004 at 8:22 am
Steve,
Thanks for your table and especially research and comments. It will be very helpful for me. Developers sometimes do ask those questions of us.
Yelena
Regards,Yelena Varsha
November 1, 2004 at 10:14 am
You're welcome. Sorry I couldn't get more detailed, but since it's Beta, I'm sure MS doesn't want to publish too much.
November 9, 2005 at 4:01 pm
You should specify that varchar(max) and nvarchar(max) are new features specific only to SQL2005 and that they make appears as if the row hold more that 8096 rows.
Varchar(max) and nvarchar(max) are the easy way to strings larger than 8000 bytes in T-SQL. In fact they are similar to text data except that string manipulations are allowed on them.
November 9, 2005 at 4:05 pm
Oups.. "as if the row hold more than 8096 bytes"
January 26, 2007 at 5:24 am
I haven't been able to find max capacity specs for Analysis Services 2005. Has anyone else seen them?
I thought I saw somewhere that any constraints have been effectively lifted.
January 26, 2007 at 5:59 am
One spec that's missing from this list is the max RAM - both Standard and Enterprise can use as much as the OS can support, either 32- or 64-bit. The new Workgroup Edition supports up to 3GB RAM just like 2000 Standard.
January 26, 2007 at 6:23 am
Errrr, I'm guessing that was a slip William, as SQL200 Standard can only support 2GB (http://msdn2.microsoft.com/en-us/library/aa933149(SQL.80).aspx).
January 26, 2007 at 6:35 am
That's right, only 2000 Enterprise can use more than 2GB. Sorry about that.
January 26, 2007 at 7:35 am
Re. max row size, standard varchar and nvarchar can exceed the row limits in 2005
http://msdn2.microsoft.com/en-us/library/ms186981.aspx
Very handy for me as I'm converting some columns from varchar(4000) to nvarchar.
January 26, 2007 at 8:51 am
You have a few errors here. Number one, the page you're referring to in this article IS NOT from Microsoft, and isn't authoritative. The actual page is at:
http://msdn2.microsoft.com/en-us/library/ms143432.aspx
And is both authoritative and correct.
Second, the BOL team does not just "cut and paste" from earlier versions. Each topic is reviewed by a development team for each release and modified accordingly. The site you're referencing IS a cut and paste, but it is not kept up to date as BOL is. BOL is updated several times a year, and Microsoft works hard to make sure it's correct. There are 48,000 pages in Books Online, and it is translated into over 9 languages, and subject to legal terms and conditions in hundreds of countries.
Third, are there errors in BOL? Of course. But each page has a section for feedback, which automatically opens a bug to the writer where you can ask about changing it. If you're correct, the writer changes the topic and the site is updated, making it better for all of us. We all depend on SQL Server to have accurate documentation, so it's best if we try and make it better all the time.
Buck Woody
MCDBA, MCSE, Novell and Sun Certified
January 26, 2007 at 8:56 am
FYI: There is a maximum capacity spec page in the RTM BOL. Keep in mind that Steve's article was published in October 2004.
Greg
Greg
January 26, 2007 at 11:52 am
What would it take MS to increase "REFERENCES per table" from 253? (This is the number of foreign keys that a table can be referred to). In a large DW or OLTP, this is way too small. Oracle is unlimited and for that they have some bragging rights.
JA
January 26, 2007 at 1:27 pm
Actually Oracle doesn't have those bragging rights. Microsoft has unlimited references per table. From the BOL note (not the page this article has referenced, but the REAL Books Online):
http://msdn2.microsoft.com/en-us/library/ms143432.aspx
4Although a table can contain an unlimited number of FOREIGN KEY constraints, the recommended maximum is 253. Depending on the hardware configuration hosting SQL Server, specifying additional foreign key constraints may be expensive for the query optimizer to process.
So it's just a matter of query processor optimizations, not a hard limit.
Buck Woody
MCDBA, MCSE, Novell and Sun Certified
January 26, 2007 at 1:28 pm
Ah - my mistake - you're referring to the REFERENCES, not REFERENCES TO! My bad.
Buck Woody
MCDBA, MCSE, Novell and Sun Certified
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply