Sorry, I could not read the content fromt this page.Sorry, I could not read the content fromt this page.
Tuesday, March 20, 2012
Microsoft Office 365 Mobile Platform
The Microsoft Office 365 mobile platform recently extended its scope by adding support for business services using BlackBerry. After spending a year in beta testing, the platform now operates on BlackBerry phones and tablets, extending its reach to make it compatible with the majority of mobile devices used in business settings.
Office 365 is a combination of software and services that extend the well-known Microsoft Office productivity suite off of the desktop and into the cloud. This enables individual users to access and edit their data anywhere through cloud storage. The platform also makes it easier for teams to work collectively thanks to online versions of tools such as Exchange, SharePoint and Lync. It includes both desktop and web versions of Office applications and ample storage. In a typical Office 365 installation, each user receives a 25 gigabyte email storage allowance coupled with 10 gigabytes of storage accessible through their company’s intranet. Microsoft also backs the platform with a 99.9 percent up time guarantee and includes the ability to set up web conferences.
On the BlackBerry platform, Office 365 has unique capabilities that make it one of the most useful business services using BlackBerry devices. It integrates with Exchange to allow BlackBerry users to access their Outlook mail. Unique to the BlackBerry platform is support for the BlackBerry Balance application that makes it easier to separate work documents, events and contacts in the Office 365 environment from personal data elsewhere on the BlackBerry device.
With attractive monthly pricing per user, Microsoft Office 365 makes it affordable for companies to give their employees the latest productivity and collaboration software. The mobile aspect of Office 365 lets the software’s productivity benefits extend past the desktop and to home computers, tablet computers and smart phones. Now that it is available for the leading business smart phone platform, Microsoft Office 365 is a complete solution for businesses needing to stay productive and connected everywhere.
Monday, March 19, 2012
WPF Datagrid and Linq to SQL
When I started working in WPF, in my first sample I tried to locate the control in the toolbox. To my surprise I couldn’t find it. I started searching it in the web for some information on that. I found though the DataGrid is not available in WPF under the framework. It is available from CodePlex for public downloading.
The above paragraph is not applicable for the .Net framework 4.0, as the .net framework 4.0 already preloaded with the WPF DataGrid control. Only difference I faced is, when you are dragging the control from the toolbox. The CodePlex DataGrid is putting defaults to the AutoGenerateColumns as true but the .Net framework control defaults the AutoGenerateColumns as false.
After downloaded from CodePlex, install it. It will not be available in the tool box right out of the box. You have to choose the installed component to be listed in the toolbox. In order to get DataGrid on Toolbox we should select from the list of components. This is available in the “Choose Tool Box Item” dialog box and under the WPF Components section.
Now no matter we are using .net Framework 4.0 or .Net Framework 3.5 we have a DataGrid to start work on. There are not many changes from the way we bind the ListBox in WPF. But here we got a lot of options as we have in GridView. For e.g., we have some standard set of predefined columns for simple usages. For advanced usages we can go for the template controls as we do in GridView.
For making this sample simpler, we go for AutoGenerateColumns = True. This has taken care of all the column creations. So we can just bind the WPF DataGrid with ItemsSource.
It is much easier to use Linq to SQL to fetch the data from the database. Firstly add the Linq to SQL class by choosing them from Add New Item window as shown in the following screen shot
Go to Add New item \ Select Linq to SQL Classes
Name it as NorthwindData.dbml
Then drag the table category from the server explorer window to the NorthwindData.dbml’s designer
Now you can simply bind the data as follows
DataGrid1.ItemsSource = (New NorthwindDataDataContext).Categories
Now it is time to move a bit to know how to use the Linq and Lambda to deal with data. Using the lambda expressions and select method of the list we are trying to transform the category object to anonymous type. Basically we don’t want to display code and picture in the DataGrid. So we don’t pass it to the control.
Though it is easier to do it with templates, I am trying to explain how to transform objects easily using the lambda expressions. Using lambda expression you can create a new anonymous type using the New With keyword. After specifying the new with whatever you are putting inside {} will become members of the anonymous type.
Using linq will be much more readable than the Lambda expressions.
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="522" Width="525" >
Class MainWindow
Private Sub Button1_Click(ByVal sender As System.Object,
ByVal e As System.Windows.RoutedEventArgs) Handles Button1.Click
Dim NorthwindProvider As New NorthwindDataDataContext
Dim CategoryList = NorthwindProvider.Categories.ToList()
DataGrid1.ItemsSource = CategoryList.Select(
Function(Category) New With
{Category.CategoryName,
Category.Description}).ToList()
Dim LinqedCategories = From Category In CategoryList
Select New With {
Category.CategoryName,
Category.Description}
DataGrid2.ItemsSource = LinqedCategories.ToList()
End Sub
End Class
Export CSV from Dataset
Before XML is widely used for data communications between the systems/applications, we have used CSV. Even now for when the new systems are being developed which needs to be communicated with these legacy applications, we have no choice if we cant choose anything other than those systems are using. I am planning to develop a class which can be useful for exporting CSV.
CSV is a character separated values format so we have to choose a character as a delimiter. As delimiters are chosen based on various factors we need our class to be delimiters configurable.
As there will be a risk if the delimiter is already present in the data, the text qualifiers are used to identify the text element’s boundary. Within this boundary if a delimiter character is present then the class will not consider it as a delimiter.
Some of the interfaces will not like headers, so make a switch to turn off the column header generations.
For generating the file with text quantifiers, surround the item with quantifier character both the side. Once done add a delimiter character next to that. If this is done for all rows then the string is ready to be written into the file system.
Imports SystemImports System.Collections.Generic
Imports System.ComponentModel
Imports System.Data
Imports System.Drawing
Imports System.Linq
Imports System.Text
Imports System.Windows.Forms
Imports System.Data.SqlClient
Imports System.IO
Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
Dim Csv As New Exporter()
Using CsvWriter As New StreamWriter("C:\TestFile.csv")
CsvWriter.Write(Csv.CsvFromDatatable(GetSampleData()))
End Using
System.Diagnostics.Process.Start("C:\TestFile.csv")
MessageBox.Show("done")
End Sub
Private Function GetSampleData() As DataTable
Dim con As New SqlConnection("Data Source=.\SQLEXPRESS;Initial Catalog=Northwind;Persist Security Info=True;Integrated Security = True")
Dim CategoryAdapter As New SqlDataAdapter("SELECT CategoryID,CategoryName,Description FROM Categories", con)
Dim ProductData As New DataSet()
CategoryAdapter.Fill(ProductData, "Categories")
Return ProductData.Tables(0)
End Function
End Class
Public Class Exporter
Public Sub New()
TextDelimiter = ","c
TextQualifiers = """"c
HasColumnHeaders = True
End Sub
Private _TextDelimiter As Char
Public Property TextDelimiter() As Char
Get
Return _TextDelimiter
End Get
Set(ByVal value As Char)
_TextDelimiter = value
End Set
End Property
Private _TextQualifiers As Char
Public Property TextQualifiers() As Char
Get
Return _TextQualifiers
End Get
Set(ByVal value As Char)
_TextQualifiers = value
End Set
End Property
Private _HasColumnHeaders As Boolean
Public Property HasColumnHeaders() As Boolean
Get
Return _HasColumnHeaders
End Get
Set(ByVal value As Boolean)
_HasColumnHeaders = value
End Set
End Property
Public Function CsvFromDatatable(ByVal InputTable As DataTable) As String
Dim CsvBuilder As New StringBuilder()
If HasColumnHeaders Then
CreateHeader(InputTable, CsvBuilder)
End If
CreateRows(InputTable, CsvBuilder)
Return CsvBuilder.ToString()
End Function
Private Sub CreateRows(ByVal InputTable As DataTable, ByVal CsvBuilder As StringBuilder)
For Each ExportRow As DataRow In InputTable.Rows
For Each ExportColumn As DataColumn In InputTable.Columns
Dim ColumnText As String = ExportRow(ExportColumn.ColumnName).ToString()
ColumnText = ColumnText.Replace(TextQualifiers.ToString(), TextQualifiers.ToString() + TextQualifiers.ToString())
CsvBuilder.Append(TextQualifiers + ColumnText + TextQualifiers)
CsvBuilder.Append(TextDelimiter)
Next
CsvBuilder.AppendLine()
Next
End Sub
Private Sub CreateHeader(ByVal InputTable As DataTable, ByVal CsvBuilder As StringBuilder)
For Each ExportColumn As DataColumn In InputTable.Columns
Dim ColumnText As String = ExportColumn.ColumnName.ToString()
ColumnText = ColumnText.Replace(TextQualifiers.ToString(), TextQualifiers.ToString() + TextQualifiers.ToString())
CsvBuilder.Append(TextQualifiers + ExportColumn.ColumnName + TextQualifiers)
CsvBuilder.Append(TextDelimiter)
Next
CsvBuilder.AppendLine()
End Sub
End Class
Replace Text in a TextBox
Everyone has probably used or at least seen the find and replace feature in programs. This allows the user to find everything that matches the specified text string and replace it. This source sample demonstrates a very bare bones version of that same functionality in Visual Basic. In general to find a sub string in a parent string you can use the InStr function which is demonstrated below. However, in order to replace the found strings with a new one you need to get a little bit trickier. See below for how this can be done in a text box.
To try out this code create a new project, add a command button to the main form, add a text box as well. Double click the command button to into the click event handler for your button. In this method add the following code.
Dim StartPos, Counter As IntegerDim FindString, ReplaceText As StringFor Counter = 1 To Len(Text1.Text) StartPos = InStr(Text1.Text, FindString) Text1.SelLength = Len(FindString) Text1.SelText = "" + ReplaceTextOnce you have the code in place run your application and add some text that has the string test in it. Hit the button and you will see all of these instances of the word test replaced with the string 'MyString'.
Note: The source for this was found at DreamVB which is no longer online.
Launch a program from VB
An often requested task that new developers to VB ask is how can I write a program that will launch other programs. Its fun to create your own little launcher program that does things like allows you to quickly launch just the programs you want. Obviously program launchers already exist out on the market that you could simply use. But one of the great things about learning a programming language like Visual Basic is that you can create your own programs that behave exactly how you want them to.
To try out the this sample source code snippet simply create a VB project, add a command button to the main form, double click this button to get into the click event handler for it and add the following code.
Filename = "C:\windows\notepad.exe" 'Check file is here first MsgBox Filename & " not found", vbInformation Res = Shell("Start.exe " & Filename, vbHide)This source code uses the VB6 Shell command to launch a new program. We specifically call the Start.exe program as it can be used to launch other programs easily.
Note: The source for this was found at DreamVB which is no longer online.
Naming Database Objects
Just as using an object and variable naming convention can help you write cleaner code, a database object naming convention can help you manage the many objects you create in a database schema. I've developed and refined a standard that has worked exceptionally well for me in my database applications. The following rules are applied to all identifiers and serve two basic objectives: Provide a reasonable degree of compatibility across various platforms. Eliminate tedious "nuisance work" delimiting identifiers with square brackets in code and SQL statements. Maximum Identifier Length: 30 Characters
This is based on the maximum length of identifiers for Microsoft SQL Server. Jet/Access databases can have much longer identifiers, but staying within the 30 character maximum is easy to accomplish and avoids naming problems if a database is scaled from Access to SQL Server. Only letters, numbers, and the underscore are allowed in names.
No spaces, punctuation, or extended characters are allowed. This provides compatibility with MS SQL Server and avoids the need to use square brackets as delimiters around identifier names in Visual Basic code and SQL statements. This provides considerable simplification when writing code and SQL statements will little or no loss in readability. A column name of CustFirst is just as easy to understand as Customer First. The first character in a name must be a letter.
This also provides compatibility with Visual Basic identifiers and eliminates the need to use square brackets. Use mixed case to delimit words where required.
The underscore can also be used to separate words in exceptional circumstances, although the use of mixed case is preferred. Use the shortest possible name without using pointless or obscure abbreviations.
Abbreviations should be avoided entirely if possible, and only used if the savings in the number of characters is significant. For example, "Itm" saves only one character in comparison to "Item" at a cost of loss of readability and added obscurity.
Be consistent in the use of abbreviations when used. For example, if you like to use "Num" for columns representing some type of count, then always use "Num" - don't use "Num" in one place and "Cnt" somewhere else.
Note: A good "rule of thumb" for identifier names is that you should be able to read them over the phone without needing to spell them out. Different database platforms, Oracle, Sybase, and so on may all impose their own restrictions on identifier names. You should develop your own standard to comply with the rules of your own platforms. In xBase compatible databases table names are limited not only by the database engine but by the file system as well. Column names are similarly restricted. For example, in Microsoft Visual FoxPro 5.0, column names for free tables are limited to 10 characters. Some of these engines (including FoxPro) do allow you to assign longer identifiers if the table is included in a data dictionary. Check the documentation for your database engine and develop your standards based on the rules it imposes. The following rules are applied for naming tables: Regular Tables
Tables are named using the plural form of the object they represent. This convention is similar to the Microsoft Consulting Services naming convention for collection classes. For example, if the table contains customer data, the name would be Customers. Junction Tables
Tables used as the junction of a many-to-many relationship use the name of both tables. For example, if a table is the junction between an Orders table and an Items table, the name would be OrdersItems. Extension Tables
Tables used as extensions to a base table in a one-to-one relationship are named using the base table name and a word describing the nature of the extension. For example, you may have a generic Persons table with basic name and address columns that has a one-to-one relationship with an extension for only a few individuals. If, for example, you have an extension table storing information specifically about people who are doctors, info for the doctors would be in the PersonsDoctors table. General rules for identifiers apply to all table names. Microsoft Access databases use a prefix of "MSys" for database engine system tables and "USys" for user-defined system tables. Microsoft SQL Server databases use a prefix of "sys" for system tables. In order to eliminate naming collisions in queries with multi-table joins, a column name prefix is determined for each table. By prefixing column names with a few characters, every column name within the name space of a database will be unique. Use an abbreviated form of the table name for the prefix.
For example, the prefix for a Customers table would be "Cust". Each prefix must be unique within the database.
This guarantees that all columns names within the database will be unique. Special rules for junction tables.
For tables that act as the junction of a many-to-many relationship, you may use either the first letter of each table, or if that is not unique, use the prefix from each of the other tables. For example, the prefix for a table named OrdersItems could be either "OI" or "OrdItem". Counter/Identity Columns
Columns with autoincrement values used as the primary key column for a table are named with the table prefix followed by "ID". For example, the primary key column for the Customers table would be CustID. All Other Columns
Use the table prefix followed by a noun describing the attribute the column represents. For a Customers table, column names would include CustFirst, CustLast, CustCity, CustState, etc. General rules for identifiers apply to all column names. The column name prefixing concept is not a standard convention in the industry, but I've found that it works well, is easily understood, and avoids a variety of problems when building queries with multi-table joins. The following rules are applied for names of indexes and contraints: Primary Key
Use "apk" followed by the name of the table. For example, the primary key for the Customers table would be apkCustomers. The table name is used because there can be only one primary key, so using the table name means you can determine the name of the index without knowing what columns are used.
Note: The "apk" prefix is used instead of the more obvious "pk" to provide compatibility with server tables attached to Jet/Access databases. When Jet attaches a remote server table, it assumes that the first index found alphabetically is the primary key. Using "apk" places this index first in an alphabetical list. Other Unique Indexes
Use "udx" followed by the names of the column or columns in the index. If, for example, you have a table of states in the U.S., you could use an autoincrement column as the primary key but define a unique index on the state name or the two character postal code (or both).
Note: Not all tables will have this kind of alternate key. Foreign Key Constraints
Use "fk" followed by the column name or names. Remember that foreign keys are defined in the table on the many side of a one-to-many relationship. For the case of a one-to-one relationship, define the foreign key on the table that is a subset of the data in the larger table.
Note: In Jet databases, foreign key constraints are called Relation objects and are managed using the relations collection. However, you can still define them using CREATE TABLE or ALTER TABLE with a CONSTRAINT clause. Clustered Indexes
Use "cdx" followed by the table name. Like a primary key, there can only be one clustered index in a table, so the table name is used based on the same reasoning as that for naming the primary key. All Other Indexes
Use "idx" followed by the name of the column or columns used in the index. General rules for identifiers apply to all indexes and constraints. Not all database engines, Jet included, support clustered indexes. If you are not familiar with clustered indexes, a clustered index is an index where the leaf pages are the actual data pages. In normal indexes, the leaf pages are pointers to data pages. If you use Microsoft Access to create your database and define relationships using the Access Relationships window, all of your foreign key constraints will have names like "Relation1", "Relation2", etc. Although it is rare to reference this type of index in code, having more useful names is helpful if you do. Most database engines do not create an index that can be used for query optimization when you define a foreign key constraint. You should add an additional index for performance reasons on any column used as a foreign key. Microsoft SQL Server and other server databases support several different types of constraints other than foreign key constraints. You can, for example, name defaults and check constraints (known as validation rules in Jet databases). Defaults
Use "def" followed by the column name. Check Constraints
Use "chk" followed by the name of the column or table, as appropriate. Rules for objects other than tables, columns, and indexes can be more difficult to define, although the general rules for identifiers are followed wherever possible. Queries
The simplest method for naming saved queries is to prefix query names based on the purpose of the query. For example, "rpt" for report record sources, "frm" for form record sources, etc. User Accounts
There are several commonly used formulas for generating user account names, but the most common is to use a comination of the names or initials of the user's name. For example, if the user's name is John Q. Public, several possibilities would be "jpublic", "johnp", and "jqp". Synchronizing database account names with network account names will simplify the life of the user by reducing the number of account names and passwords the user needs to remember.
Note: Some database systems, including Microsoft SQL Server, allow you to use security systems that are integrated with the network security system, making the management of user accounts easier for both administrators and users. Stored Procedures
The SQL Server convention is to use "sp" as a prefix to the procedure name. Extended stored procedures are prefixed with "xp". Triggers
In most cases there will be three types of triggers available: insert, update, and delete. Trigger names use a combination of either "i", "u", or "d" to represent the type of trigger and the table name. If the trigger is used for more than one operation, the appropriate characters are combined.
Note: Jet databases do not support triggers. Just as is the case with variable and object naming conventions in Visual Basic code, the particular convention you choose is less important than developing or adopting a convention and following it faithfully. Rather than thinking of a naming convention as yet another complex set of rules to follow, it is helpful to think of a naming convention as a means of simplifying the task of database design and development. A well thought-out naming convention makes your life as a developer easier by eliminating one area of decision making (or at least consolidating that decision making process into the process of developing the naming convention) and making the design more consistent by applying a set of standards to at least one area.
This is based on the maximum length of identifiers for Microsoft SQL Server. Jet/Access databases can have much longer identifiers, but staying within the 30 character maximum is easy to accomplish and avoids naming problems if a database is scaled from Access to SQL Server. Only letters, numbers, and the underscore are allowed in names.
No spaces, punctuation, or extended characters are allowed. This provides compatibility with MS SQL Server and avoids the need to use square brackets as delimiters around identifier names in Visual Basic code and SQL statements. This provides considerable simplification when writing code and SQL statements will little or no loss in readability. A column name of CustFirst is just as easy to understand as Customer First. The first character in a name must be a letter.
This also provides compatibility with Visual Basic identifiers and eliminates the need to use square brackets. Use mixed case to delimit words where required.
The underscore can also be used to separate words in exceptional circumstances, although the use of mixed case is preferred. Use the shortest possible name without using pointless or obscure abbreviations.
Abbreviations should be avoided entirely if possible, and only used if the savings in the number of characters is significant. For example, "Itm" saves only one character in comparison to "Item" at a cost of loss of readability and added obscurity.
Be consistent in the use of abbreviations when used. For example, if you like to use "Num" for columns representing some type of count, then always use "Num" - don't use "Num" in one place and "Cnt" somewhere else.
Note: A good "rule of thumb" for identifier names is that you should be able to read them over the phone without needing to spell them out. Different database platforms, Oracle, Sybase, and so on may all impose their own restrictions on identifier names. You should develop your own standard to comply with the rules of your own platforms. In xBase compatible databases table names are limited not only by the database engine but by the file system as well. Column names are similarly restricted. For example, in Microsoft Visual FoxPro 5.0, column names for free tables are limited to 10 characters. Some of these engines (including FoxPro) do allow you to assign longer identifiers if the table is included in a data dictionary. Check the documentation for your database engine and develop your standards based on the rules it imposes. The following rules are applied for naming tables: Regular Tables
Tables are named using the plural form of the object they represent. This convention is similar to the Microsoft Consulting Services naming convention for collection classes. For example, if the table contains customer data, the name would be Customers. Junction Tables
Tables used as the junction of a many-to-many relationship use the name of both tables. For example, if a table is the junction between an Orders table and an Items table, the name would be OrdersItems. Extension Tables
Tables used as extensions to a base table in a one-to-one relationship are named using the base table name and a word describing the nature of the extension. For example, you may have a generic Persons table with basic name and address columns that has a one-to-one relationship with an extension for only a few individuals. If, for example, you have an extension table storing information specifically about people who are doctors, info for the doctors would be in the PersonsDoctors table. General rules for identifiers apply to all table names. Microsoft Access databases use a prefix of "MSys" for database engine system tables and "USys" for user-defined system tables. Microsoft SQL Server databases use a prefix of "sys" for system tables. In order to eliminate naming collisions in queries with multi-table joins, a column name prefix is determined for each table. By prefixing column names with a few characters, every column name within the name space of a database will be unique. Use an abbreviated form of the table name for the prefix.
For example, the prefix for a Customers table would be "Cust". Each prefix must be unique within the database.
This guarantees that all columns names within the database will be unique. Special rules for junction tables.
For tables that act as the junction of a many-to-many relationship, you may use either the first letter of each table, or if that is not unique, use the prefix from each of the other tables. For example, the prefix for a table named OrdersItems could be either "OI" or "OrdItem". Counter/Identity Columns
Columns with autoincrement values used as the primary key column for a table are named with the table prefix followed by "ID". For example, the primary key column for the Customers table would be CustID. All Other Columns
Use the table prefix followed by a noun describing the attribute the column represents. For a Customers table, column names would include CustFirst, CustLast, CustCity, CustState, etc. General rules for identifiers apply to all column names. The column name prefixing concept is not a standard convention in the industry, but I've found that it works well, is easily understood, and avoids a variety of problems when building queries with multi-table joins. The following rules are applied for names of indexes and contraints: Primary Key
Use "apk" followed by the name of the table. For example, the primary key for the Customers table would be apkCustomers. The table name is used because there can be only one primary key, so using the table name means you can determine the name of the index without knowing what columns are used.
Note: The "apk" prefix is used instead of the more obvious "pk" to provide compatibility with server tables attached to Jet/Access databases. When Jet attaches a remote server table, it assumes that the first index found alphabetically is the primary key. Using "apk" places this index first in an alphabetical list. Other Unique Indexes
Use "udx" followed by the names of the column or columns in the index. If, for example, you have a table of states in the U.S., you could use an autoincrement column as the primary key but define a unique index on the state name or the two character postal code (or both).
Note: Not all tables will have this kind of alternate key. Foreign Key Constraints
Use "fk" followed by the column name or names. Remember that foreign keys are defined in the table on the many side of a one-to-many relationship. For the case of a one-to-one relationship, define the foreign key on the table that is a subset of the data in the larger table.
Note: In Jet databases, foreign key constraints are called Relation objects and are managed using the relations collection. However, you can still define them using CREATE TABLE or ALTER TABLE with a CONSTRAINT clause. Clustered Indexes
Use "cdx" followed by the table name. Like a primary key, there can only be one clustered index in a table, so the table name is used based on the same reasoning as that for naming the primary key. All Other Indexes
Use "idx" followed by the name of the column or columns used in the index. General rules for identifiers apply to all indexes and constraints. Not all database engines, Jet included, support clustered indexes. If you are not familiar with clustered indexes, a clustered index is an index where the leaf pages are the actual data pages. In normal indexes, the leaf pages are pointers to data pages. If you use Microsoft Access to create your database and define relationships using the Access Relationships window, all of your foreign key constraints will have names like "Relation1", "Relation2", etc. Although it is rare to reference this type of index in code, having more useful names is helpful if you do. Most database engines do not create an index that can be used for query optimization when you define a foreign key constraint. You should add an additional index for performance reasons on any column used as a foreign key. Microsoft SQL Server and other server databases support several different types of constraints other than foreign key constraints. You can, for example, name defaults and check constraints (known as validation rules in Jet databases). Defaults
Use "def" followed by the column name. Check Constraints
Use "chk" followed by the name of the column or table, as appropriate. Rules for objects other than tables, columns, and indexes can be more difficult to define, although the general rules for identifiers are followed wherever possible. Queries
The simplest method for naming saved queries is to prefix query names based on the purpose of the query. For example, "rpt" for report record sources, "frm" for form record sources, etc. User Accounts
There are several commonly used formulas for generating user account names, but the most common is to use a comination of the names or initials of the user's name. For example, if the user's name is John Q. Public, several possibilities would be "jpublic", "johnp", and "jqp". Synchronizing database account names with network account names will simplify the life of the user by reducing the number of account names and passwords the user needs to remember.
Note: Some database systems, including Microsoft SQL Server, allow you to use security systems that are integrated with the network security system, making the management of user accounts easier for both administrators and users. Stored Procedures
The SQL Server convention is to use "sp" as a prefix to the procedure name. Extended stored procedures are prefixed with "xp". Triggers
In most cases there will be three types of triggers available: insert, update, and delete. Trigger names use a combination of either "i", "u", or "d" to represent the type of trigger and the table name. If the trigger is used for more than one operation, the appropriate characters are combined.
Note: Jet databases do not support triggers. Just as is the case with variable and object naming conventions in Visual Basic code, the particular convention you choose is less important than developing or adopting a convention and following it faithfully. Rather than thinking of a naming convention as yet another complex set of rules to follow, it is helpful to think of a naming convention as a means of simplifying the task of database design and development. A well thought-out naming convention makes your life as a developer easier by eliminating one area of decision making (or at least consolidating that decision making process into the process of developing the naming convention) and making the design more consistent by applying a set of standards to at least one area.
Originally written by Joe Garrick
Subscribe to:
Posts (Atom)