private void btnOK_Click(object sender, System.EventArgs e)
{
try
{
emps.Save();
}
catch
{
MessageBox.Show("You need to generate the stored procedures for 'Employees' and 'Products' to be able to save. Use 'SQL_StoredProcs.vbgen' to generate them.");
}
this.DialogResult = DialogResult.OK;
}
public void DataSetSerialize()
{
Employees emps = new Employees();
emps.LoadAll(); // emps.RowCount = 200
emps.LastName = "Griffinski"; // Change first row
emps.GetChanges(); // emps.RowCount now = 1
string str = emps.Serialize();
// Now reload that single record into a new Employees object and Save it
Employees empsClone = new Employees();
empsClone.Deserialize(str);
empsClone.Save();
}
public void DemonstrateBulkUpdates()
{
Employees emps = new Employees();
if (emps.LoadAll())
{
// Modify the LastName column in every row
do
{
emps.LastName += "W";
}while(emps.MoveNext());
}
// Rewind and mark the first row as Deleted
//emps.Rewind();
//emps.MarkAsDeleted();
// Add a new row and fill it in
emps.AddNew();
emps.FirstName = "Jimmy";
emps.LastName = "Lunch Box";
// Save all modifications, deletes, and new rows
emps.Save();
//-----------------------------------------------------------
// Moral:
//-----------------------------------------------------------
// This is a very nice way to work. When you generate your
// stored procedures using 'SQL_StoredProcs.vbgen' you'll find
// it is pretty smart. It makes any identity columns
// and or computed columns as OUTPUT parameters. Thus, after Save()
// any new rows or updated rows have their identity
// columns or calulated columns already in them, no
// requerying the database
//
// You never have to use a transaction when saving a single object.
// The dOOdad architecture always does this for you.
//-----------------------------------------------------------
}
public void Serialize()
{
Employees emps = new Employees();
emps.LoadAll(); // emps.RowCount = 200
emps.LastName = "Griffinski"; // Change first row
emps.GetChanges(); // emps.RowCount now = 1
string str = emps.ToXml();
// Now reload that single record into a new Employees object and Save it
Employees empsClone = new Employees();
empsClone.FromXml(str);
empsClone.Save();
//-----------------------------------------------------------
// Moral:
//-----------------------------------------------------------
// This really only serializes the data in the embedded DataTable.
// However, the methods used in the sample above our virtual
// so you can override them.
//-----------------------------------------------------------
}
public void DataSetSerialize()
{
Employees emps = new Employees();
emps.LoadAll(); // emps.RowCount = 200
emps.LastName = "Griffinski"; // Change first row
emps.GetChanges(); // emps.RowCount now = 1
string str = emps.Serialize();
// Now reload that single record into a new Employees object and Save it
Employees empsClone = new Employees();
empsClone.Deserialize(str);
empsClone.Save();
}
public void Serialize()
{
Employees emps = new Employees();
emps.LoadAll(); // emps.RowCount = 200
emps.LastName = "Griffinski"; // Change first row
emps.GetChanges(); // emps.RowCount now = 1
string str = emps.ToXml();
// Now reload that single record into a new Employees object and Save it
Employees empsClone = new Employees();
empsClone.FromXml(str);
empsClone.Save();
//-----------------------------------------------------------
// Moral:
//-----------------------------------------------------------
// This really only serializes the data in the embedded DataTable.
// However, the methods used in the sample above our virtual
// so you can override them.
//-----------------------------------------------------------
}
public void Transactions()
{
TransactionMgr tx = TransactionMgr.ThreadTransactionMgr();
try
{
Employees emps = new Employees();
emps.AddNew();
emps.FirstName = "Jimmy";
emps.LastName = "Lunch Box";
Products prds = new Products();
prds.AddNew();
prds.ProductName = "dOOdads";
prds.Discontinued = false;
tx.BeginTransaction();
emps.Save();
prds.Save();
tx.CommitTransaction();
}
catch(Exception)
{
tx.RollbackTransaction();
TransactionMgr.ThreadTransactionMgrReset();
}
//-----------------------------------------------------------
// Moral:
//-----------------------------------------------------------
// Modeled after COM+ transactions, but still using ADO.NET
// connection based transactions you have the best of both
// worlds.
//
// 1) Your transactions paths do not have to be pre-planned.
// At any time you can begin a transaction
//
// 2) You can nest BeginTransaction/CommitTransaction any number of times as
// long as they are sandwiched appropriately
//
// BeginTransaction
// BeginTransaction
// emps.Save
// CommitTransaction
// CommitTransaction
//
// Only the final CommitTransaction will commit the transaction
//
// 3) Once RollbackTransaction is called the transaction is doomed,
// nothing can be committed even it is attempted.
//
// 4) Transactions are stored in the Thread Local Storage or
// TLS. This way the API isn't intrusive, ie, forcing you
// to pass a SqlConnection around everywhere. There is one
// thing to remember, once you call RollbackTransaction you will
// be unable to commit anything on that thread until you
// call ThreadTransactionMgrReset().
//
// In an ASP.NET application each page is handled by a thread
// that is pulled from a thread pool. Thus, you need to clear
// out the TLS (thread local storage) before your page begins
// execution. The best way to do this is to create a base page
// that inhertis from System.Web.UI.Page and clears the state
// like this
//
// public class MyPage : System.Web.UI.Page
// {
// private void Page_Init(System.Object sender, System.EventArgs e)
// {
// TransactionMgr.ThreadTransactionMgrReset();
// }
// }
//
// And then make sure all of your ASPX pages inherit from MyPage.
//
//-----------------------------------------------------------
}
public void DemonstrateBulkUpdates()
{
Employees emps = new Employees();
if(emps.LoadAll())
{
// Modify the LastName column in every row
do
emps.LastName += "W";
while(emps.MoveNext());
}
// Rewind and mark the first row as Deleted
//emps.Rewind();
//emps.MarkAsDeleted();
// Add a new row and fill it in
emps.AddNew();
emps.FirstName = "Jimmy";
emps.LastName = "Lunch Box";
// Save all modifications, deletes, and new rows
emps.Save();
//-----------------------------------------------------------
// Moral:
//-----------------------------------------------------------
// This is a very nice way to work. When you generate your
// stored procedures using 'SQL_StoredProcs.vbgen' you'll find
// it is pretty smart. It makes any identity columns
// and or computed columns as OUTPUT parameters. Thus, after Save()
// any new rows or updated rows have their identity
// columns or calulated columns already in them, no
// requerying the database
//
// You never have to use a transaction when saving a single object.
// The dOOdad architecture always does this for you.
//-----------------------------------------------------------
}
public void Transactions()
{
TransactionMgr tx = TransactionMgr.ThreadTransactionMgr();
try
{
Employees emps = new Employees();
emps.AddNew();
emps.FirstName = "Jimmy";
emps.LastName = "Lunch Box";
Products prds = new Products();
prds.AddNew();
prds.ProductName = "dOOdads";
prds.Discontinued = false;
tx.BeginTransaction();
emps.Save();
prds.Save();
tx.CommitTransaction();
}
catch (Exception)
{
tx.RollbackTransaction();
TransactionMgr.ThreadTransactionMgrReset();
}
//-----------------------------------------------------------
// Moral:
//-----------------------------------------------------------
// Modeled after COM+ transactions, but still using ADO.NET
// connection based transactions you have the best of both
// worlds.
//
// 1) Your transactions paths do not have to be pre-planned.
// At any time you can begin a transaction
//
// 2) You can nest BeginTransaction/CommitTransaction any number of times as
// long as they are sandwiched appropriately
//
// BeginTransaction
// BeginTransaction
// emps.Save
// CommitTransaction
// CommitTransaction
//
// Only the final CommitTransaction will commit the transaction
//
// 3) Once RollbackTransaction is called the transaction is doomed,
// nothing can be committed even it is attempted.
//
// 4) Transactions are stored in the Thread Local Storage or
// TLS. This way the API isn't intrusive, ie, forcing you
// to pass a SqlConnection around everywhere. There is one
// thing to remember, once you call RollbackTransaction you will
// be unable to commit anything on that thread until you
// call ThreadTransactionMgrReset().
//
// In an ASP.NET application each page is handled by a thread
// that is pulled from a thread pool. Thus, you need to clear
// out the TLS (thread local storage) before your page begins
// execution. The best way to do this is to create a base page
// that inhertis from System.Web.UI.Page and clears the state
// like this
//
// public class MyPage : System.Web.UI.Page
// {
// private void Page_Init(System.Object sender, System.EventArgs e)
// {
// TransactionMgr.ThreadTransactionMgrReset();
// }
// }
//
// And then make sure all of your ASPX pages inherit from MyPage.
//
//-----------------------------------------------------------
}
