Woo Hoo
Wow, I just returned from DevCon 2005, and I am really excited about what the buzz was around the conference. First, we have the preview of Borland Developer Studio (BDS) 2006, this thing rocks and is looking better every single day. The developer features, the SUPPORT FOR C++, the Together Modeling – Audits –Metrics support, and the awesome new capabilities being added to ECO III… if you have been waiting for a reason to upgrade from your older Delphi versions 1 – 2005, then this looks awesome. I will write more about ECO III in the future.
My talks on CORE::SDP, Java, and optimization were less attended then some of the great talks on BDS, but I had a great group of attendees that were very interactive and I believe they got a lot out of the sessions. There is just a ton of power in the tools that most people have limited experience with and every time I show these capabilities, people seem to walk away with a nugget of GOLD.
From the Sorry Department:
For those of you that went to DevCon this year, you noticed that your welcome package had a white paper compiled by yours truly. It is 38 pages long and focuses on a Re-Introduction to InterBase. It was brought to my attention that we had a typo in the document and I wanted to explain how that happened. In the InterBase Enterprise Limits section of the paper, some of the numbers that used superscript formatting did not convert from the basic document written in Word to the PDF format. I have posted the table below that you should replace the section with. That has also been fixed moving forward with the document and when it is posted for others or used in other places inside Borland it will be updated.
InterBase Enterprise Limits:
| Maximum number of clients connected to one server
| There is no single number for the maximum number of clients the InterBase server can serve—it depends on a combination of factors including capability of the operating system, limitations of the hardware, and the demands that each client puts on the server.
Applications that engage in high levels of contention or that perform complex or high-volume operations could cause the practical number of clients to be fewer. In applications that don’t generate much contention, InterBase can support a large number of users, where “large” is not well-defined.
|
| Maximum database size
| No limit is imposed by InterBase. Maximum size is defined by the operating system
|
| Maximum number of files per database
| By design, 216 (65,536) because the files are enumerated with an unsigned 16-bit integer. Shadow files count toward this limit.
This is a design parameter of InterBase, but most operating systems have a much lower limit on the number of files that a single process can have open simultaneously. In some cases, the OS provides a means to raise this limit.
Refer to your OS documentation for the default open files limit, and the means to raise this limit.
|
| Maximum number of cache pages per database
| 65,536 for the sake of performance. A more practical upper limit would be 10,000. Total size of cache pages should never exceed 50% of memory.
|
| Maximum number of databases open in one transaction
| No restriction. The parameters in a transaction parameter buffer comprise a linked list, so there is no limit except that imposed by system resources.
|
| Maximum number of tables per database
| 32,640
|
| Maximum versions per table
| 255. Then, no more metadata changes until the database has been backed up and restored.
|
| Maximum row size
| 64KB. Each Blob and array contributes eight bytes to this limit in the form of their Blob handle.
Systems tables (tables maintained by the InterBase engine for system data) have a row size limit of 128KB.
|
| Maximum number of rows and columns per table
| By design, 232 rows because rows are enumerated with a 32-bit unsigned integer per table.
Number of columns in a row depends on datatypes used.
One row can be 64K. For example, you can define 16,384 columns of type INTEGER (four bytes each) in one table.
|
| Maximum number of indexes per table
| By design, 216 (65,536) because indexes per table are enumerated with a 16-bit unsigned integer.
|
| Maximum number of indexes per database
| By design, 232 because you can create 216 tables per database, and each table can have 216 indexes.
|
| Maximum index key size
| Multi-column keys. Subtract four bytes for each additional column.
Example: a single-column CHAR key can be up to 256 – 4 = 252 bytes; a three-column key must add up to 200 – 12 = 188 bytes.
Note that multi-byte character sets must fit within the key by counting bytes, not by counting characters. For example, a single-column key using 3-byte UNICODE_FSS characters can have a maximum of (256 – 4) / 3 = 84 characters.
It is good practice to keep index keys as small as possible.
This limits the depth of indexes and increases their efficiency.
|
| Maximum number of events per stored procedure
| No restriction by design, but there is a practical limit, given that there is a limit on the length of code in a stored procedure or trigger (see below).
|
| Maximum stored procedure
Share This | Email this page to a friend Leave a ReplyBad Behavior has blocked 2 access attempts in the last 7 days.
Close
|
