HTML5 tables and borders

Since a few years ago, if you put in a table without ANY css, you are going to get a borderless table. Worse, if you put borders="1"  you will get the ugly, nasty  way old-school HTML double borders.  Worse STILL, even if you put the css for 1px solid black , you will STILL get the ugly double borders!!

The secret is to set the borders-collapse: to collapse.  (the default value is SEPARATE).




<style>
table {
    border-collapse: collapse;
}

table, td, th {
    border: 1px solid black;
}
</style>

Microsoft Fail

(should be 6 and 4)
And no, there are NO comments correcting this below.

Clustered Index

a CLUSTERED index determines the PHYSICAL location (order) of data in a table. That's why you can only have ONE clustered index per table.


A Primary Key constraints will automatically create a CLUSTERED INDEX on that column.

-can have multiple columns (a COMPOSITE index)


Execute sp_helpindex tblEmployee
to view indexes.


You can change clustered index.  First:

Drop Index tblEmployee.PK_tblEmplo_3FD45DG   (or might have to use Object Explorer to Delete)

Create Clustered Index tblEmployee_Gender_Salary on tblEmployee (Gender DESC, Salary ASC)


CLUSTERED includes Data: think PHONEBOOK
NON-CLUSTERED is separate from data: think index to a BOOK

Since the index is stored separately, you CAN have MORE THAN ONE non-clustered indexes per table.

CLUSTERED INDEX is faster because it involves a single lookup, whereas NON-CLUSTERED has to do a second step to access the data location.  Also, NON-CLUSTERED requires EXTRA STORAGE SPACE for itself.

----
set statistics io on

(then write your select query)

After running, view Messages.

----

For viewing execution plan,
TABLE SCAN is when there isn't an index.
An INDEX SEEK would be more efficient.


----

Downside of Indexing is when you have lots of writes/updates (transactions) to a table.

-----
Naming conventions:
IX prefix means Index.
UIX means UNIQUE index.

See if someone changed table in SQL Server

SELECT

[name]

,create_date

,modify_date

FROM

sys.tables 

Encryption

SQL Server version 12 has lots of new encryption options.
(to tell version of SQL Server, use: Select @@version    )



Transparent
Column-level
use .NET
use File System
BitLocker

Page that describes options: http://sqlmag.com/database-security/sql-server-encryption-options
UPDATE: Apparently that site fell victim to the Goths and Vandals. Reprinted below.

SQL Server Encryption Options

May 17, 2013Michael Otey

One of the most difficult-to-understand options in SQL Server 2012 is the ability to encrypt data. This is mainly because of all of the different encryption capabilities offered.

Data encryption can be performed by the OS, by SQL Server, or by the application. I’ll help guide you through the different SQL Server encryption options.

Related: SQL Server Encryption

1. Transparent Data Encryption

Transparent Data Encryption (TDE) is the primary SQL Server encryption option. It was first available in SQL Server 2008, and as with the SQL Server 2012 release, it's available only in the SQL Server Enterprise edition, not in the Business Intelligence, Standard, or Express editions. TDE enables you to encrypt an entire database. Backups for databases that use TDE are also encrypted. TDE protects the data at rest, which means that the database’s data and log files are encrypted using the AES and 3DES encryption algorithms. TDE is completely transparent to the application and requires no coding changes to implement. For more information on TDE, check out "Transparent Data Encryption," on MSDN and my SQL Server Pro article "Using Transparent Data Encryption."

Related: Transparent Data Encryption FAQs

2. Column-level Encryption

Column-level encryption (aka cell-level encryption) was introduced in SQL Server 2005 and is available in all editions of SQL Server, including the free SQL Server Express edition. To use cell-level encryption, the schema must be changed to varbinary, then reconverted to the desired data type. This means the application must be changed to support the encryption-decryption operation; in addition, it can affect performance. Encryption of the database occurs at the page level, but when those pages are read to buffer pool, they're decrypted. Data can be encrypted using a passphrase, an asymmetric key, a symmetric key, or a certificate.  The supported algorithms for column-level encryption are AES with 128,196,256 bit keys and 3DES. To learn more about column-level encryption, see the MSDN article "Encrypt a Column of Data."

Related: Protecting the Database With Encryption

3. Encrypting and Decrypting Data with the .NET Framework

Another option for encrypting data stored in SQL Server is to perform the encryption and decryption from within the application. All editions of SQL Server support this style of data encryption. However, unlike TDE, encrypting data within the application requires that you specifically code the application to perform the encryption by calling the encryption and decryption methods. The .NET Framework supports encryption using the System.Security.Cryptography namespace to perform symmetric or asymmetric encryption. You can learn more about .NET-based encryption at "Encrypting and Decrypting Data." Application-level encryption can also be performed by other development frameworks such as Java.

4. Encrypting File Systems

Encrypting File Systems (EFS) is a file-encryption feature introduced in Windows 2000. Windows Server supports EFS for encrypting data at the file and folder level. EFS uses industry-standard encryption algorithms including AES, SHA, ECC, and smart card–based encryption.  Installing a SQL Server database in EFS isn't usually a recommended practice because of the added overhead. EFS isn't optimized for performance, and all I/O is synchronous. If you use EFS, the database files are encrypted under the identity of the account running SQL Server. If you change the account that runs the SQL Server service, you must first decrypt the files using the old account, then re-encrypt them using the new account. You can learn about the performance implications of running SQL Server and EFS at the Microsoft Support web page.

5. BitLocker

BitLocker Drive Encryption is a data protection feature available in Windows Server 2012, Windows 8, Windows 7, and Windows Server 2008 R2. BitLocker works at the volume level, and it protects data when it's at rest by using the AES algorithm. BitLocker doesn't have the same performance concerns associated with EFS. You can learn more about BitLocker at the Microsoft article, "BitLocker Driver Encryption Overview."

Cluster vs. Farm

"Farm was generally used in load balancing scenarios and Clusters are generally used in high available(resilant) solutions.  In the web applications, a Farm is also a cluster because putting a switch infront of more than one machine and the DNS record for the web site is nothing but the IP address of the switch.  The switch depending on how  busy a server is routes the traffic to different machines.

Cluster, is usually a two machine node where one machine is active and other is passive (or active/active in true cluster environment).  But the processing is handled by only one machine and the other one is dormant.  When the active machine goes down, the other node takes over.

Farm is mainly used in web applications (stateless apps) where as clusters are used in database, server (windows service) type applications."

.NET Session State

https://msdn.microsoft.com/en-us/library/ms178586(v=vs.100).aspx
UPDATE: newer version of all this at: https://docs.microsoft.com/en-us/iis/application-frameworks/scenario-build-an-aspnet-website-on-iis/planning-step-2-plan-asp-net-settings

and
https://docs.microsoft.com/en-us/iis/application-frameworks/scenario-build-an-aspnet-website-on-iis/configuring-step-2-configure-asp-net-settings

Session-State Modes

.NET Framework 4

Other Versions

ASP.NET session state supports several different storage options for session data. Each option is identified by a value in theSessionStateMode enumeration. The following list describes the available session state modes:

• InProc mode, which stores session state in memory on the Web server. This is the default.
• StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
• Custom mode, which enables you to specify a custom storage provider.
• Off mode, which disables session state.

You can specify which mode you want ASP.NET session state to use by assigning a SessionStateMode enumeration values to the modeattribute of the sessionState element in your application's Web.config file. Modes other than InProc and Off require additional parameters, such as connection-string values as discussed later in this topic. You can view the currently selected session state by accessing the value of the HttpSessionState.Mode property.

In-Process Mode

In-process mode is the default session state mode and is specified using the InProc SessionStateMode enumeration value. In-process mode stores session state values and variables in memory on the local Web server. It is the only mode that supports theSession_OnEnd event. For more information about the Session_OnEnd event, see Session-State Events.

Caution:
If you enable Web-garden mode by setting the webGarden attribute to true in the processModel element of the application's Web.config file, do not use InProc session state mode. If you do, data loss can occur if different requests for the same session are served by different worker processes.

State Server Mode

StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

To use StateServer mode, you must first be sure the ASP.NET state service is running on the server used for the session store. The ASP.NET state service is installed as a service when ASP.NET and the .NET Framework are installed. The ASP.Net state service is installed at the following location:

systemroot\Microsoft.NET\Framework\versionNumber\aspnet_state.exe

To configure an ASP.NET application to use StateServer mode, in the application's Web.config file do the following:

• Set the mode attribute of the sessionState element to StateServer.
• Set the stateConnectionString attribute to tcpip=serverName:42424.

  Note:
  To improve the security of your application when using StateServer mode, it is recommended that you protect yourstateConnectionString value by encrypting the sessionState section of your configuration file. For details, see Encrypting Configuration Information Using Protected Configuration.

The following example shows a configuration setting for StateServer mode where session state is stored on a remote computer named SampleStateServer:

<configuration>
  <system.web>
    <sessionState mode="StateServer"
      stateConnectionString="tcpip=SampleStateServer:42424"
      cookieless="false"
      timeout="20"/>
  </system.web>
</configuration>

Note:
Objects stored in session state must be serializable if the mode is set to StateServer. For information on serializable objects, see the SerializableAttribute class.

To use StateServer mode in a Web farm, you must have the same encryption keys specified in the machineKey element of your Web configuration for all applications that are part of the Web farm. For information on how to create machine keys, see article 313091, "How to create keys by using Visual Basic .NET for use in Forms authentication," in the Microsoft Knowledge Base at http://support.microsoft.com.

SQL Server Mode

SQLServer mode stores session state in a SQL Server database. Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.

Note:
Objects stored in session state must be serializable if the mode is SQL Server. For information on serializable objects, see theSerializableAttribute class.

To use SQLServer mode, you must first be sure the ASP.NET session state database is installed on SQL Server. You can install the ASP.NET session state database using the Aspnet_regsql.exe tool, as described later in this topic.

To configure an ASP.NET application to use SQLServer mode, do the following in the application's Web.config file:

• Set the mode attribute of the sessionState element to SQLServer.
• Set the sqlConnectionString attribute to a connection string for your SQL Server database.

  Note:
  to improve the security of your application when using SQLServer mode, it is recommended that you protect yoursqlConnectionString value by encrypting the sessionState section of your configuration file. For details, see Encrypting Configuration Information Using Protected Configuration.

The following example shows a configuration setting for SQLServer mode where session state is stored on a SQL Server named "SampleSqlServer":

<configuration>
  <system.web>
    <sessionState mode="SQLServer"
      sqlConnectionString="Integrated Security=SSPI;data 
        source=SampleSqlServer;" />
  </system.web>
</configuration>

Note:

If you specify a trusted connection to your SQL Server in the configuration file using the sessionState element'ssqlConnectionString attribute, the SessionStateModule will connect to SQL Server using SQL Server integrated security. The connection will be made using the ASP.NET process identity or the user credentials supplied for the identity configuration element, if they exist. You can specify that the IIS impersonated identity be used instead by specifying <identity impersonate="true" /> and setting the useHostingIdentity attribute of the sessionState configuration element to false. For more information on the ASP.NET process identity, see Configuring ASP.NET Process Identity and ASP.NET Impersonation.

To configure SQLServer mode for a Web farm, in the configuration file for each Web server, set the sessionState element'ssqlConnectionString attribute to point to the same SQL Server database. The path for the ASP.NET application in the IIS metabase must be identical on all Web servers that share session state in the SQL Server database. For information on steps to resolve the issue when application paths differ between servers, see article 325056, "PRB: Session State Is Lost in Web Farm If You Use SqlServer or StateServer Session Mode," in the Microsoft Knowledge Base at http://support.microsoft.com.

Installing the Session State Database Using the Aspnet_regsql.exe Tool

To install the session state database on SQL Server, run the Aspnet_regsql.exe tool located in thesystemroot\Microsoft.NET\Framework\versionNumber folder on your Web server. Supply the following information with the command:

• Thename of the SQL Server instance, using the -S option.
• The logon credentials for an account that has permission to create a database on SQL Server. Use the -E option to use the currently logged-on user, or use the -U option to specify a user ID along with the -P option to specify a password.
• The -ssadd command-line option to add the session state database.
  By default, you cannot use the Aspnet_regsql.exe tool to install the session state database on SQL Server Express Edition. In order to run the Aspnet_regsql.exe tool to install a SQL Server Express Edition database, you must first enable the Agent XPsSQL Server option using Transact-SQL commands like the following:
  EXECUTE sp_configure 'show advanced options', 1
  RECONFIGURE WITH OVERRIDE
  GO
  
  EXECUTE sp_configure 'Agent XPs', 1
  RECONFIGURE WITH OVERRIDE
  GO
  
  EXECUTE sp_configure 'show advanced options', 0
  RECONFIGURE WITH OVERRIDE
  GO
  

  You must run these Transact-SQL commands for any instance of SQL Server Express Edition where the Agent XPs option is disabled.

By default, the Aspnet_regsql.exe tool will create a database named ASPState containing stored procedures that support SQLServermode. Session data itself is stored in the tempdb database by default. You can optionally use the -sstype option to change the storage location of session data. The following table specifies the possible values for the -sstype option:

Option	Description
t	Stores session data in the SQL Server tempdb database. This is the default. If you store session data in the tempdb database, the session data is lost if SQL Server is restarted.
p	Stores session data in the ASPState database instead of in the tempdb database.
c	Stores session data in a custom database. If you specify the c option, you must also include the name of the custom database using the -d option.

For example, the following command creates a database named ASPState on a SQL Server instance named "SampleSqlServer" and specifies that session data is also stored in the ASPState database:

aspnet_regsql.exe -S SampleSqlServer -E -ssadd -sstype p

Note:

If you are running ASP.NET 1.0 or ASP.NET 1.1, you cannot use the Aspnet_regsql.exe tool to configure ASP.NET to store session state in a persistent SQL Server database. However, you can obtain scripts to store session state in a persistent database. For details, see article 311209, "HOW TO: Configure ASP.NET for Persistent SQL Server Session State Management" in the Microsoft Knowledge Base at http://support.microsoft.com. As an alternative, Web servers running ASP.NET 1.0 or ASP.NET 1.1 can direct persistent session state to a SQL Server that has the ASP.NET 2.0 session state schema installed.

In SQLServer mode, you can configure several computers running SQL Server to work as a failover cluster, which is two or more identical computers running SQL Server that store data for a single database. If one computer running SQL Server fails, another server in the cluster can take over and serve requests without session-data loss. To configure SQL Server mode for a failover cluster, you must specify -sstype p when you execute the Aspnet_regsql.exe tool so that session state data is stored in the ASPState database instead of the tempdb database. Storing session state in the tempdb database is not supported for a SQL Server cluster. For more information about setting up SQL Server mode for a failover cluster, see article 323262, "How to use ASP.NET session state SQL Server Mode in a failover cluster" in the Microsoft Knowledge Base at http://support.microsoft.com.

Custom Mode

Custom mode specifies that you want to store session state data using a custom session state store provider. When you configure your ASP.NET application with a Mode of Custom, you must specify the type of the session state store provider using the providerssub-element of the sessionState configuration element. You specify the provider type using an add sub-element and include both atype attribute that specifies the provider's type name and a name attribute that specifies the provider instance name. The name of the provider instance is then supplied to the customProvider attribute of the sessionState element to configure ASP.NET session state to use that provider instance for storing and retrieving session data.

The following example shows elements from a Web.config file that specify that ASP.NET session state use a custom session state store provider:

<configuration>
  <connectionStrings>
    <add name="OdbcSessionServices" 
      connectionString="DSN=SessionState;" />
  </connectionStrings>

  <system.web>
    <sessionState 
      mode="Custom"
      customProvider="OdbcSessionProvider">
      <providers>
        <add name="OdbcSessionProvider"
          type="Samples.AspNet.Session.OdbcSessionStateStore"
          connectionStringName="OdbcSessionServices" 
          writeExceptionsToEventLog="false" />
      </providers>
    </sessionState>
  </system.web>
</configuration>

For more information on custom session state store providers, see Implementing a Session-State Store Provider.

Note:

A custom session state store provider will access any secured resource, such as SQL Server, using the ASP.NET process identity or the user credentials supplied to the identity configuration element, if they exist. You can specify that the IIS impersonated identity be used instead by specifying <identity impersonate="true" /> and setting the useHostingIdentity attribute of thesessionState configuration element to false. For more information on the ASP.NET process identity, see Configuring ASP.NET Process Identity and ASP.NET Impersonation.