Author: Jason Hiner
The CIO and CTO job roles are frequently confused, but there are clear distinctions between the two positions in most large enterprises. The two require different skill sets and are focused on different goals.
——————————————————————————————————————
When you start talking about IT leadership roles and IT career tracks, the question that almost always comes up is “What’s the difference between the CIO and CTO positions?”
Here’s a quick breakdown of the distinguishing characteristics of those two roles.
Chief Information Officer
* Serves as the company’s top technology infrastructure manager
* Runs the organization’s internal IT operations
* Works to streamline business processes with technology
* Focuses on internal customers (users and business units)
* Collaborates and manages vendors that supply infrastructure solutions
* Aligns the company’s IT infrastructure with business priorities
* Developers strategies to increase the company’s bottom line (profitability)
* Has to be a skilled and organized manager to be successful
Chief Technology Officer
* Serves as the company’s top technology architect
* Runs the organization’s engineering group
* Uses technology to enhance the company’s product offerings
* Focuses on external customers (buyers)
* Collaborates and manages vendors that supply solutions to enhance the company’s product(s)
* Aligns the company’s product architecture with business priorities
* Develops strategies to increase the company’s top line (revenue)
* Has to be a creative and innovative technologist to be successful
Monday, July 21, 2008
The five reasons I wouldn’t use an iPhone are down to one
Author: Jason Hiner
Two of the most common technology questions that I’ve been asked over the past year are “Have you used the iPhone?” and “What makes it so special?” I typically respond that TechRepublic has an iPhone and that the product isn’t perfect nor is it a phone for everyone, but it’s a watershed device that will change mobile computing.
For those who want to know more, I explain that there two reasons why the iPhone is revolutionary. At the point, many people have asked me why I don’t use the device, since I think it’s such a revolution. I have typically replied with five reasons why I wouldn’t want to use it — the first-generation iPhone — on a day-to-day basis.
Take a look at the two things that I think make the iPhone revolutionary, the five reasons I didn’t use the original iPhone, and the one reason why I still won’t use the iPhone 3G.
Why the iPhone is revolutionary
The iPhone made the full Web browsing experience useful on a cell phone for the first time. That is its greatest triumph. Instead of relying on dumbed-down mobile versions of Web sites, with the iPhone you can pull up almost any site on the Internet and get a decent browsing experience, with a few exceptions (some technologies such as Flash and ActiveX don’t work on the iPhone).
What has made the iPhone a fully-capable Web browsing device is its touch-based user-interface, the iPhone’s other revolutionary fearure. Specifically, the iPhone’s pinch-to-zoom feature has made it very easy to zoom in and out of full-sized Web pages. Plus, the rest of the touch-based interface makes it a fast and intuitive to navigate the iPhone.
Five reasons I didn’t use the original iPhone
1. Speed – The bad thing about loading up full-size Web pages is that most of them are quite large. Many sites seem to assume users have fast broadband. As a result, the iPhone’s Web browser is abysmally slow when connected over the cellular network (and still not super-fast when connected via Wi-Fi). Many sites never even load at all. The iPhone 3G is better, but there are still times when a non-3G BlackBerry or Treo will load a mobile Web page far faster than the iPhone 3G will load the full Web page from the site.
2. Price –At $499 (4 GB) and $599 (8 GB), the original iPhone was way too pricey for me to justify, and I’m sure many IT departments felt the same way. Apple eventually dropped the price of the 8 GB iPhone to $399, but that wasn’t low enough for me, since the iPhone still had other limitations as well. Of course, the iPhone 3G has dropped the price to a more palatable $199 (8 GB) and $299 (16 GB).
3. E-mail –The primary reason that I use my smartphone is for checking e-mail. Since the first iPhone did not include support for push e-mail and could not connect to Microsoft Exchange it simply was not a viable replacement for a Treo, BlackBerry, or Windows Mobile device. Apple has rectified that by building Exchange ActiveSync support into the iPhone 3G.
4. Headphone jack –Although it’s nitpicky, one of the most maddening features of the original iPhone was its recessed headphone jack. This meant that you could only use Apple’s proprietary headphones, which don’t fit my ears and hurt whenever I try. The only other option was to buy an adapter to make the jack compatible with normal headphones. Thankfully, Apple has replaced this with a standard jack in the iPhone 3G.
5. Keyboard – For me, the worst feature of the original iPhone was its on-screen keyboard. While it’s better and more intuitive than the on-screen keyboard in Windows Mobile and other devices, it is still not very useful when you need to do any kind of serious typing. It’s just too slow and error-prone. It really forces you to hunt-and-peck with one finger. I have much better luck using my thumbs on the qwerty keyboards that come on most smartphones.
Will I use the iPhone 3G?
Apple rectified the first four items on my list with the iPhone 3G, but unfortunately the on-screen keyboard remains. If the iPhone 3G had a slide-down qwerty keyboard in landscape mode, I would have seriously considered adopting it. However, without a usable keyboard the device is still just an innovative, ground-breaking piece of technology that doesn’t quite have a place in my day-to-day life yet. And, I also wouldn’t recommend it to any IT leaders or business users who need to do a significant amount of typing from a smartphone.
Two of the most common technology questions that I’ve been asked over the past year are “Have you used the iPhone?” and “What makes it so special?” I typically respond that TechRepublic has an iPhone and that the product isn’t perfect nor is it a phone for everyone, but it’s a watershed device that will change mobile computing.
For those who want to know more, I explain that there two reasons why the iPhone is revolutionary. At the point, many people have asked me why I don’t use the device, since I think it’s such a revolution. I have typically replied with five reasons why I wouldn’t want to use it — the first-generation iPhone — on a day-to-day basis.
Take a look at the two things that I think make the iPhone revolutionary, the five reasons I didn’t use the original iPhone, and the one reason why I still won’t use the iPhone 3G.
Why the iPhone is revolutionary
The iPhone made the full Web browsing experience useful on a cell phone for the first time. That is its greatest triumph. Instead of relying on dumbed-down mobile versions of Web sites, with the iPhone you can pull up almost any site on the Internet and get a decent browsing experience, with a few exceptions (some technologies such as Flash and ActiveX don’t work on the iPhone).
What has made the iPhone a fully-capable Web browsing device is its touch-based user-interface, the iPhone’s other revolutionary fearure. Specifically, the iPhone’s pinch-to-zoom feature has made it very easy to zoom in and out of full-sized Web pages. Plus, the rest of the touch-based interface makes it a fast and intuitive to navigate the iPhone.
Five reasons I didn’t use the original iPhone
1. Speed – The bad thing about loading up full-size Web pages is that most of them are quite large. Many sites seem to assume users have fast broadband. As a result, the iPhone’s Web browser is abysmally slow when connected over the cellular network (and still not super-fast when connected via Wi-Fi). Many sites never even load at all. The iPhone 3G is better, but there are still times when a non-3G BlackBerry or Treo will load a mobile Web page far faster than the iPhone 3G will load the full Web page from the site.
2. Price –At $499 (4 GB) and $599 (8 GB), the original iPhone was way too pricey for me to justify, and I’m sure many IT departments felt the same way. Apple eventually dropped the price of the 8 GB iPhone to $399, but that wasn’t low enough for me, since the iPhone still had other limitations as well. Of course, the iPhone 3G has dropped the price to a more palatable $199 (8 GB) and $299 (16 GB).
3. E-mail –The primary reason that I use my smartphone is for checking e-mail. Since the first iPhone did not include support for push e-mail and could not connect to Microsoft Exchange it simply was not a viable replacement for a Treo, BlackBerry, or Windows Mobile device. Apple has rectified that by building Exchange ActiveSync support into the iPhone 3G.
4. Headphone jack –Although it’s nitpicky, one of the most maddening features of the original iPhone was its recessed headphone jack. This meant that you could only use Apple’s proprietary headphones, which don’t fit my ears and hurt whenever I try. The only other option was to buy an adapter to make the jack compatible with normal headphones. Thankfully, Apple has replaced this with a standard jack in the iPhone 3G.
5. Keyboard – For me, the worst feature of the original iPhone was its on-screen keyboard. While it’s better and more intuitive than the on-screen keyboard in Windows Mobile and other devices, it is still not very useful when you need to do any kind of serious typing. It’s just too slow and error-prone. It really forces you to hunt-and-peck with one finger. I have much better luck using my thumbs on the qwerty keyboards that come on most smartphones.
Will I use the iPhone 3G?
Apple rectified the first four items on my list with the iPhone 3G, but unfortunately the on-screen keyboard remains. If the iPhone 3G had a slide-down qwerty keyboard in landscape mode, I would have seriously considered adopting it. However, without a usable keyboard the device is still just an innovative, ground-breaking piece of technology that doesn’t quite have a place in my day-to-day life yet. And, I also wouldn’t recommend it to any IT leaders or business users who need to do a significant amount of typing from a smartphone.
Wednesday, July 16, 2008
10 reasons to turn your Access applications into Web-based applications
By Susan Sales Harkins and Drew Wutka
An Access database often outgrows its original purpose. When that happens, you face applying band-aid technology or upgrading to a more powerful database system, such as SQL Server Express or even SQL Server. But before you toss Access out the window and start signing purchase orders for consultants, developers, licensing, and new hardware, consider one more option—turning your Access application into a Web-based application. Let's look at some reasons why this might make sense.
Shameless disclaimer: If you truly need a more powerful database system and can afford its trappings, spend and grow!
Client versus server
A server-side database, such as MySQL, SQL Server, and Oracle, evaluates requests on the server side (sent in the form of a SQL statement) and then returns data to the client. Jet, on the other hand, lets the client do all the work. Jet is the database engine behind Access. Even if the database (.mdb) is on a network server, the client still does all the work. The server simply responds to client file requests.
This arrangement retrieves more then just the data across the network. As a result, indexes and unused data clog the network and slow things down. An alternative is to place the Access database on your Web server's local drive and then build the interface on the Web server. Doing so creates an ad hoc server-side database that handles transactions on the server (using your code). Requests from the client are in Hyper Text Transfer Protocol (HTTP) format instead of SQL.
Recommendation: Put the Access database (the .mdb file) in a folder that isn't shared. That way, users won't have direct access to the database. Their only access will be via the Web server. Your code will serve as the layer that allows users to interact with the actual data.
No client installation
A Web-based front end minimizes installation issues. Users need only a browser. The database doesn't care whether the user is sending requests via a Windows PC, a Mac, or a machine running Linux.
Easy cross-platform usage
You're free to use your language of choice to create the Web interface and the code that the server users to interact with the database. Users get clean and standard HTML that almost all browsers can use.
Recommendation: Keep the Web interface simple to ensure that everyone can use it. If you need the advantages of client-side tools, such as client side scripting, Flash media, and so on, go for it. Just keep in mind that not every HTML feature works in every browser. The back end can be as complex as necessary because the Web server is the only one using it.
Simplified security
Storing the database in a non-shared folder (see #1) restricts access. Only the Web server's administrator has access to the database file. That leaves security to the Web server. Now, you might argue either way as to whether this method is more or less secure than a server-side database. However, someone with direct access to a machine with a server-side database could probably also gain direct access to that database.
In addition, a server-side database requires a network connection. An Access database on a Web server isn't directly available. You can access the Web server, but not the database. Only the Web server can access the database on the server's local drive. On the other hand, Access has a security system known as Access User Level security (this isn't available with Access 2007). Most server-side database security systems are more secure than Access User Level security.
Recommendation: Even though you impose an almost absolute-type form of security by placing a database on a Web server, it can't hurt to apply Access User Level security. The database is still an .mdb that you can copy and open on any machine that has Access installed. As a developer, you will probably have local copies of that .mdb (and copies on backup tapes for your Web server). Be on the safe side and keep honest people honest by putting a little extra security in place. Users via the Web interface won't even know the additional security is there.
Easy use of NT authentication
Using Visual Basic for Applications (VBA), you can determine the NT name of users logged into an Access database and thereby restrict which users can do what. However, this method isn't foolproof, and it doesn't truly authenticate users. Your Web interface (on an IIS Web server) can use Integrated Windows Security to authenticate user credentials to individual Web pages
Goodbye to corruption!
Most developers complain that Access is susceptible to corruption. Used incorrectly, it certainly is. With an Uninterruptible Power Source (UPS) and redundant drives, your Web-based database (.mdb file) won't suffer from corruption
No version problems
With the quick pace of upgrades, many of us have users spread across two and three versions of Access. Unfortunately, not all versions play well together. A Web interface eliminates version incompatibility issues because the Web server uses Jet. That means the Web server doesn't even need Access—it doesn't load Access. Your Web server doesn't care what version of Access the client uses.
Live, behind-the-scenes interface updates
To update an Access front end, you must copy or modify an .mdb file. Access won't let you make changes while people are using it. (Beginning with Access 2000, you can make some changes, but a few still require exclusive access to the database.) In contrast, you can change the Web interface files (.asp, .aspx, and so on) whenever you like. The changes are almost immediate.
Portability
Every Windows OS since Windows 98 has had personal Web server capabilities. That means you can develop and test a Web site using a laptop running Windows 98 (or later). Using an Access database as the data source has a few benefits:
• There's no need to install and run a heavy-duty server-side database on your laptop.
• There's no need to maintain a network connection to a live server.
• You can copy the live system and its database as just a bunch of files. You don't have to import, export, or attach database files. For example, you can build a Web site on your laptop or desktop and then move it to a Web server. To work on an update, simply copy the Access database file (.mdb) from the Web server to your laptop.
Recommendation: Jet allows many transaction type SQL statements. You can build and modify tables and views using SQL, along with the typical data reading and altering capabilities. Sometimes, if you put a system on a remote server where you no longer have the ability to get to the actual .mdb, it's pretty simple to whip up an .asp page that lets you run SQL on the fly against the database.
More users
By their very nature, Web interfaces are unbound. In other words, once a page is loaded, the interface is no longer connected to the database. But a bound Access front end maintains a connection to the source, and Jet limits you to 255 concurrent connections. Your Web application, unless you have 255 users hitting the database at the exact same moment (which would require approximately 30,000 users a minute at a transactions speed of .5 seconds) can have more concurrent users.
Susan Sales Harkins is an independent consultant and the author of several articles and books on database technologies. Her most recent book is Mastering Microsoft SQL Server 2005 Express, with Mike Gunderloy, published by Sybex. Other collaborations with Gunderloy are Automating Microsoft Access 2003 with VBA, Upgrader’s Guide to Microsoft Office System 2003, ICDL Exam Cram 2, and Absolute Beginner's Guide to Microsoft Access 2003, all published by Que. Currently, Susan volunteers as the Publications Director for Database Advisors. You can reach her at ssharkins@gmail.com.
Drew Wutka is a Microsoft Access/Visual Basic/Web developer for Marlow Industries, Inc. He also does independent contract development and has developed many free projects, such as the Microsoft Access MiniCalendar, the Dynamic FrontPage Navigation ASP Sitemap, and the Password Enabled Enigma Encryption VB program. You can reach Drew at Drew@wolfwares.com.
An Access database often outgrows its original purpose. When that happens, you face applying band-aid technology or upgrading to a more powerful database system, such as SQL Server Express or even SQL Server. But before you toss Access out the window and start signing purchase orders for consultants, developers, licensing, and new hardware, consider one more option—turning your Access application into a Web-based application. Let's look at some reasons why this might make sense.
Shameless disclaimer: If you truly need a more powerful database system and can afford its trappings, spend and grow!
Client versus server
A server-side database, such as MySQL, SQL Server, and Oracle, evaluates requests on the server side (sent in the form of a SQL statement) and then returns data to the client. Jet, on the other hand, lets the client do all the work. Jet is the database engine behind Access. Even if the database (.mdb) is on a network server, the client still does all the work. The server simply responds to client file requests.
This arrangement retrieves more then just the data across the network. As a result, indexes and unused data clog the network and slow things down. An alternative is to place the Access database on your Web server's local drive and then build the interface on the Web server. Doing so creates an ad hoc server-side database that handles transactions on the server (using your code). Requests from the client are in Hyper Text Transfer Protocol (HTTP) format instead of SQL.
Recommendation: Put the Access database (the .mdb file) in a folder that isn't shared. That way, users won't have direct access to the database. Their only access will be via the Web server. Your code will serve as the layer that allows users to interact with the actual data.
No client installation
A Web-based front end minimizes installation issues. Users need only a browser. The database doesn't care whether the user is sending requests via a Windows PC, a Mac, or a machine running Linux.
Easy cross-platform usage
You're free to use your language of choice to create the Web interface and the code that the server users to interact with the database. Users get clean and standard HTML that almost all browsers can use.
Recommendation: Keep the Web interface simple to ensure that everyone can use it. If you need the advantages of client-side tools, such as client side scripting, Flash media, and so on, go for it. Just keep in mind that not every HTML feature works in every browser. The back end can be as complex as necessary because the Web server is the only one using it.
Simplified security
Storing the database in a non-shared folder (see #1) restricts access. Only the Web server's administrator has access to the database file. That leaves security to the Web server. Now, you might argue either way as to whether this method is more or less secure than a server-side database. However, someone with direct access to a machine with a server-side database could probably also gain direct access to that database.
In addition, a server-side database requires a network connection. An Access database on a Web server isn't directly available. You can access the Web server, but not the database. Only the Web server can access the database on the server's local drive. On the other hand, Access has a security system known as Access User Level security (this isn't available with Access 2007). Most server-side database security systems are more secure than Access User Level security.
Recommendation: Even though you impose an almost absolute-type form of security by placing a database on a Web server, it can't hurt to apply Access User Level security. The database is still an .mdb that you can copy and open on any machine that has Access installed. As a developer, you will probably have local copies of that .mdb (and copies on backup tapes for your Web server). Be on the safe side and keep honest people honest by putting a little extra security in place. Users via the Web interface won't even know the additional security is there.
Easy use of NT authentication
Using Visual Basic for Applications (VBA), you can determine the NT name of users logged into an Access database and thereby restrict which users can do what. However, this method isn't foolproof, and it doesn't truly authenticate users. Your Web interface (on an IIS Web server) can use Integrated Windows Security to authenticate user credentials to individual Web pages
Goodbye to corruption!
Most developers complain that Access is susceptible to corruption. Used incorrectly, it certainly is. With an Uninterruptible Power Source (UPS) and redundant drives, your Web-based database (.mdb file) won't suffer from corruption
No version problems
With the quick pace of upgrades, many of us have users spread across two and three versions of Access. Unfortunately, not all versions play well together. A Web interface eliminates version incompatibility issues because the Web server uses Jet. That means the Web server doesn't even need Access—it doesn't load Access. Your Web server doesn't care what version of Access the client uses.
Live, behind-the-scenes interface updates
To update an Access front end, you must copy or modify an .mdb file. Access won't let you make changes while people are using it. (Beginning with Access 2000, you can make some changes, but a few still require exclusive access to the database.) In contrast, you can change the Web interface files (.asp, .aspx, and so on) whenever you like. The changes are almost immediate.
Portability
Every Windows OS since Windows 98 has had personal Web server capabilities. That means you can develop and test a Web site using a laptop running Windows 98 (or later). Using an Access database as the data source has a few benefits:
• There's no need to install and run a heavy-duty server-side database on your laptop.
• There's no need to maintain a network connection to a live server.
• You can copy the live system and its database as just a bunch of files. You don't have to import, export, or attach database files. For example, you can build a Web site on your laptop or desktop and then move it to a Web server. To work on an update, simply copy the Access database file (.mdb) from the Web server to your laptop.
Recommendation: Jet allows many transaction type SQL statements. You can build and modify tables and views using SQL, along with the typical data reading and altering capabilities. Sometimes, if you put a system on a remote server where you no longer have the ability to get to the actual .mdb, it's pretty simple to whip up an .asp page that lets you run SQL on the fly against the database.
More users
By their very nature, Web interfaces are unbound. In other words, once a page is loaded, the interface is no longer connected to the database. But a bound Access front end maintains a connection to the source, and Jet limits you to 255 concurrent connections. Your Web application, unless you have 255 users hitting the database at the exact same moment (which would require approximately 30,000 users a minute at a transactions speed of .5 seconds) can have more concurrent users.
Susan Sales Harkins is an independent consultant and the author of several articles and books on database technologies. Her most recent book is Mastering Microsoft SQL Server 2005 Express, with Mike Gunderloy, published by Sybex. Other collaborations with Gunderloy are Automating Microsoft Access 2003 with VBA, Upgrader’s Guide to Microsoft Office System 2003, ICDL Exam Cram 2, and Absolute Beginner's Guide to Microsoft Access 2003, all published by Que. Currently, Susan volunteers as the Publications Director for Database Advisors. You can reach her at ssharkins@gmail.com.
Drew Wutka is a Microsoft Access/Visual Basic/Web developer for Marlow Industries, Inc. He also does independent contract development and has developed many free projects, such as the Microsoft Access MiniCalendar, the Dynamic FrontPage Navigation ASP Sitemap, and the Password Enabled Enigma Encryption VB program. You can reach Drew at Drew@wolfwares.com.
10+ tips for getting the best performance out of your SQL Server data types
By Susan Sales Harkins
Data integrity and performance are the driving force behind almost every decision you make during the design and development process. Defining appropriate data types is one of the easiest ways to let SQL Server help you help yourself.
Size matters
Always use the smallest data size that will accommodate the largest possible value. If a column is going to store values between 1 and 5, use tinyint instead of int. This rule also applies to character columns. The smaller the data size, the less there is to read, so performance, over all, benefits. In addition, smaller size reduces network traffic. With newer technology, this tip seems less relevant, but don't dismiss it out of hand. You'll won't regret being efficient from the get-go.
Bad primary keys
Don't use float, real, or datetime for primary keys. They add overhead that you just don't need, and given the nature of primary keys, you will probably feel the pinch.
Usurp SQL Server assumptions
When converting a value to a variable length data type using varchar, always specify the length. Otherwise, SQL Server assumes a default size of 30. Specify the smallest size possible (see #1).
Faster sorts
To speed up frequent sorts, use an int (or an integer-based) data type if possible. SQL Server sorts integer data faster than character data.
Efficient strings
The text data type accommodates a lot of data but at a cost. Unfortunately, I have seen developers use it by default. For those large columns, use varchar instead; it accommodates up to 8,000 characters and requires less overhead. Consequently, varchar performs better.
The varchar instead of char trade off
It's best to limit a text column, but knowing just how much can be difficult. If the data varies in length, it can be more efficient to use varchar than char. A fixed-length data type will waste space on smaller entries. In addition, sorts against a varchar column are usually faster. That's because SQL Server sorts the entire width of a char column.
Don't store NULL in fixed-length columns
Try not to allow NULL values in a fixed-length column. NULL consumes the same space an input value would. Those NULL values will add up quickly in a large column. If you must accommodate NULL values, use a variable-length column. They use less space for NULL.
Avoid bigint
SQL Server's bigint uses 8 bytes of memory. In comparison, int uses just 4. Don't use bigint unless the data forces you to.
Avoid sql_variant
Avoid using SQL Server's sql_variant data type. It's a memory hog and comes with limits that make it difficult to work with:
• Variants can't be part of a primary or foreign key.
• Variants can't be part of a computed column.
• Variants don't work with LIKE in a WHERE clause.
• OLE DB and ODBC providers automatically convert variants to nvarchar(4000) a huge waste almost 100% of the time!
When numbers are really text
It's common to store numeric values as text. For instance, you won't (mathematically) evaluate a ZIP Code or a phone number, so you might store them as text. However, numeric data types generally consume less overhead to store the same value as a character data type. You'll probably notice a difference between the two data types in a WHERE clause, a sort, or a join.
Data integrity and performance are the driving force behind almost every decision you make during the design and development process. Defining appropriate data types is one of the easiest ways to let SQL Server help you help yourself.
Size matters
Always use the smallest data size that will accommodate the largest possible value. If a column is going to store values between 1 and 5, use tinyint instead of int. This rule also applies to character columns. The smaller the data size, the less there is to read, so performance, over all, benefits. In addition, smaller size reduces network traffic. With newer technology, this tip seems less relevant, but don't dismiss it out of hand. You'll won't regret being efficient from the get-go.
Bad primary keys
Don't use float, real, or datetime for primary keys. They add overhead that you just don't need, and given the nature of primary keys, you will probably feel the pinch.
Usurp SQL Server assumptions
When converting a value to a variable length data type using varchar, always specify the length. Otherwise, SQL Server assumes a default size of 30. Specify the smallest size possible (see #1).
Faster sorts
To speed up frequent sorts, use an int (or an integer-based) data type if possible. SQL Server sorts integer data faster than character data.
Efficient strings
The text data type accommodates a lot of data but at a cost. Unfortunately, I have seen developers use it by default. For those large columns, use varchar instead; it accommodates up to 8,000 characters and requires less overhead. Consequently, varchar performs better.
The varchar instead of char trade off
It's best to limit a text column, but knowing just how much can be difficult. If the data varies in length, it can be more efficient to use varchar than char. A fixed-length data type will waste space on smaller entries. In addition, sorts against a varchar column are usually faster. That's because SQL Server sorts the entire width of a char column.
Don't store NULL in fixed-length columns
Try not to allow NULL values in a fixed-length column. NULL consumes the same space an input value would. Those NULL values will add up quickly in a large column. If you must accommodate NULL values, use a variable-length column. They use less space for NULL.
Avoid bigint
SQL Server's bigint uses 8 bytes of memory. In comparison, int uses just 4. Don't use bigint unless the data forces you to.
Avoid sql_variant
Avoid using SQL Server's sql_variant data type. It's a memory hog and comes with limits that make it difficult to work with:
• Variants can't be part of a primary or foreign key.
• Variants can't be part of a computed column.
• Variants don't work with LIKE in a WHERE clause.
• OLE DB and ODBC providers automatically convert variants to nvarchar(4000) a huge waste almost 100% of the time!
When numbers are really text
It's common to store numeric values as text. For instance, you won't (mathematically) evaluate a ZIP Code or a phone number, so you might store them as text. However, numeric data types generally consume less overhead to store the same value as a character data type. You'll probably notice a difference between the two data types in a WHERE clause, a sort, or a join.
Protecting Document with Password
You can protect your document by applying password so that unauthorized person can not display as well as modify your document. You can apply two types of passwords:
Password to open the document:
If it is applied then you have to give the correct password to open the document, otherwise you cannot open the document.
Password to modify the document:
If it is applied then you have to give the correct password to modify the document, otherwise your document is opened but you cannot modify the document. It means that your document becomes read-only.
To apply a password to document, follow these steps.
* Open Save As dialog box by selecting "Save As" command from File menu.
* Click "Tools" button of Save As dialog box and choose "General Options" from drop down menu, "Save" dialog box appears as shown in figure below.
* Enter first password in "Password to open" text box and second password in "Password to modify" text box (if required) and click "Ok" button of dialog box. Microsoft Word will open "Confirm Password" dialog box for the confirmation of passwords. The maximum length of password is 15 characters.
* Re-enter the password to open and password to modify and click "Ok" button of Confirm Password dialog boxes one by one.
* Click "Save" button of Save As dialog box.
Password to open the document:
If it is applied then you have to give the correct password to open the document, otherwise you cannot open the document.
Password to modify the document:
If it is applied then you have to give the correct password to modify the document, otherwise your document is opened but you cannot modify the document. It means that your document becomes read-only.
To apply a password to document, follow these steps.
* Open Save As dialog box by selecting "Save As" command from File menu.
* Click "Tools" button of Save As dialog box and choose "General Options" from drop down menu, "Save" dialog box appears as shown in figure below.
* Enter first password in "Password to open" text box and second password in "Password to modify" text box (if required) and click "Ok" button of dialog box. Microsoft Word will open "Confirm Password" dialog box for the confirmation of passwords. The maximum length of password is 15 characters.
* Re-enter the password to open and password to modify and click "Ok" button of Confirm Password dialog boxes one by one.
* Click "Save" button of Save As dialog box.
Subscribe to:
Posts (Atom)