The DataTable control provides a simple yet powerful API to display screen-reader accessible tabular data on a web page.

Im using it right now to populate a list so the user can personalize customization of the dataset at the presentation layer. Im excited because the YUI even supports Data Updates from the Presentation Layer on the user’s front-end.

So I have been experimenting and trying to extend the layer component design of the DataTable control with my own Design Patterns for a more managable web interface

100 ms of increase in web-time to display a page forcasts 1 - 3 % sales lost.
– Nicole Sullivan, Yahoo! Exceptional Performance Team Guide
Exceptional Performance :
14+ Best Practices for Speeding Up Your Web Site

To rename a MSSQL database, run this code in Web Analyzer::

sp_renamedb >oldname< , >newname<

remember you must first make the database accessible by ONLY  -m “one user”
then you can run this SQL script…

If a backup BAK is provided how to you go about restoring in Web Analyzer?

Here’s how

RESTORE FILELISTONLY FROM DISK
=’D:\Sites\…\***NAME HERE****.bak’

This revealed within your .bak file :
SQLDBName_Data  D:\Data\MSSQL\data\***NAME HERE****_Data.MDF

SQLDBName_Log   D:\Data\MSSQL\data\***NAME HERE****_Log.LDF

Then created all destination directories as desired to reflect intended instruction set of the next string::

RESTORE DATABASE ****NEW NAME HERE****

FROM DISK = ‘D:\Sites\***NAME HERE****_db.bak’

WITH REPLACE, MOVE ‘***NAME HERE****_Data’
TO ‘D:\Sites\databases\***NAME HERE****_Data.MDF’,

MOVE ‘***NAME HERE****_Log’
TO ‘D:\Sites\databases\data\***NAME HERE****_Log.LDF’, STATS

< ?xml version=”1.0″ encoding=”utf-8″ ?>

<configuration>

   <appSettings>

      <add key=”ApplicationTitle” value=”Sample Console Application” />

      <add key=”ConnectionString”

value=”Server=localhost;Database=Northwind;Integrated

                  Security=false;User Id=sa;Password=;” />

   </appSettings>

</configuration>

The AppSettings property of the ConfigurationSettings object in the System.Configuration namespace is used to get the settings. For example, to read either of the settings above, the following sample code would do the trick:

// Read appSettings

string title = ConfigurationSettings.AppSettings[”ApplicationTitle”];

string connectString =

ConfigurationSettings.AppSettings["ConnectionString"];

Now, you could easily set a dynamic title value or read database connection string information from the application configuration file. This gives you the freedom to adjust settings without having to recompile any code.

then just pass it into say a SQL connection like so :

SQLConnection cnn = new   SQLConnection ( connectString ); // there ya go !

The Datatel Messaging Interface (DMI) is a communications protocol that enables your institution to communicate with any Colleague or Benefactor account. DMI acts as a bridge between Colleague and Benefactor accounts and other Datatel application interfaces by transmitting Envision process data and information in a client-server environment. It is currently the communications interface for WebAdvisor and the CampusCruiser portal, Blackboard and WebCT learning management systems interfaces, FA-COD and SEVIS regulatory interfaces, and will be the communications interface for future applications.

The most current version of DMI is DMI 3.3. DMI 3.0 is also currently supported and available to download. Other DMI-related software downloads are also available from the Datatel for niche wares.

Code Access Security Facts

Code access security restricts the resources a particular piece of code can access, thus protecting the system from untrusted or possibly buggy code. Code access security allows varying degrees of trust to be applied to those code segments.

As with role-based security, code-access security follows two models: imperative and declarative. These models reflect the models of the role-based security, namely, imperative security demands and permissions are made in the code, while declarative demands and permissions are attributes which are tagged onto assemblies, classes and members.

There are a number of classes that you can use in the imperative model, each inherits from System.Security.CodeAccessPermission. To use imperative code-access security, select the class that best fits your needs, or create your own custom permission class by inheriting from System.Security.CodeAccessPermission. Common permissions include:

• DirectoryServicesPermission to control access to data in Windows Directory Service.
• FileIOPermission to control access to files.
• SqlClientPermission to control access to a SQL data source.
• RegistryPermission to control access to registry variables.

The following example defines an access level (Read permission) and uses the PermitOnly method to check the user’s permissions. If permissions do not match those specified, a SecurityException will be thrown.

public void Process()
{
FileIOPermission fp =
new FileIOPermission(FileIOPermissionAccess.Read,
@"C:\");
try
{
fp.PermitOnly();
// Correct permission process
}
catch (SecurityException ex)
{
// Incorrect permission process
}
}

To used declarative code access security use one of the CodeAccessSecurityAttribute classes to tag an assembly, class or class member. There are a number of attribute classes that derive from System.Security.Permissions.CodeAccessSecurityAttribute. In fact, they basically mirror the CodeAccessSecurity classes.

Any assembly, class, or class member tagged with a CodeAccessSecurityAttribute must have the specified permission(s), otherwise a SecurityException will be thrown.

[FileIOPermissionAttribute(SecurityAction.PermitOnly,
Read=@"C:\")]
public void Process()
{
// process here
}

Role-based Security Facts

The table below describes three role-based security terms you should know.

In .NET, role-based security includes the process of checking a user’s authentication information against the roles (or permissions) that the user is assigned. It is up to the programmer to enforce role-based security in the application.

The table below describes the four class and attribute implementations upon which role-based security relies.

Identity and Principal classes represent passive objects; they simply encapsulate user and permission information. PrincipalPermission and the PrincipalPermissionAttribute are active objects; they perform the security demands when appropriate.

The following table lists several methods and properties available through these classes.

The exact mechanisms you use to implement security depends on whether you will be using imperative or declarative security. The following table shows implementation examples of each approach:

try
{
PrincipalPermission permissions =
new PrincipalPermission("DEMO/demo", "User");
permissions.Demand();
// If the user is a member of the role,
// additional statements will run
}
// If the user is not a member of the role,
// an exception will be thrown
catch(SecurityException ex)
{
// Actions based on invalid security credentials
}

using System.Security;
using System.Security.Permissions;

[PrincipalPermissionAttribute(
SecurityAction.Demand,
Name="DEMO/demo",
Role="User")]
public void SecureProcess()
{
// The code will only be executed if
// the security checks are passed
}

Security Facts

When working with application security, it’s important to understand the difference between authentication and authorization:

• Authentication is the process of ensuring that users are who they say they are. Authentication typically uses a user name and a password.
• Authorization happens after authentication and identifies the level of access allowed to a given user. For example, authorization might identify specific files to which the user has access.

.NET uses two mechanisms for controlling security:

• Code access security allows you to specify what resources your code should and should not be able to access and what operations your code can and cannot perform. Code access security in .NET allows different segments of code to be trusted at different degrees, thus minimizing the need for full trust (which is dangerous) of the system.
• Role-based security allows you to specify what permissions a particular user has, often based on the role (or Windows group) of the user.

  If you get an error like “System.Security.Policy.Exception: Failed to aquire required permissions” you can run the Permissions View Tool (Permview.exe) on the Server to view the permissions required by components you are trying to configure to run…

There are two models of implementing each type of security: declarative and imperative.

• With declarative security, assemblies, classes, and class members are tagged with security attributes that identify the security rules to apply to the assembly, class, or class member. .NET automatically controls access based on the security attributes.
• With imperative security, the permissions and demands are placed directly in the code. They are applied at runtime as the code is encountered. The programmer is responsible for identifying when and how to apply security restrictions.

In general, not only the caller must meet the security criteria, but also the entire call stack is also traced (or walked) and each subsequent caller is required to have the appropriate permissions. This prevents untrusted methods from using more trusted objects and methods to access secure resources. This behavior can be overridden

great text editor controls for users to provide feedback

openWYSIWYG link here 

Q. When a control in a Web form generates a postback, ASP.NET scrolls back to the top of the page. Can you prevent this unwanted scrolling so a page retains its scroll position even after posting back to the server?

A. You bet. The scrolling isn’t really ASP.NET’s doing — at least not directly. It’s a consequence of the fact that posting back to the server causes a brand-new page to be generated and returned to the browser. It’s annoying to click on a date in a Calendar control and suddenly find yourself back at the top of the page. The page in Figure 1 demonstrates this behavior in spades. Scroll down and click on any of the controls at the bottom of the page, and — presto! — you go right back to the top.

<html>
<body>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
<form runat=”server”>
<asp:Button Text=”Test” RunAt=”server” /><br>
<asp:LinkButton Text=”Test” RunAt=”server” /><br>
<asp:Calendar RunAt=”server” />
</form>
</body>
</html>

Figure 1. Clicking on any of the controls in the Web form above scrolls back to the top of the page because it generates a postback.

The solution is to save the scroll position before the postback occurs and restore it afterward. One way to do this is to replace the page’s <body> tag with these (many thanks to reader Shaun Walker for his contribution to the ensuing logic):

<%
if (Request[”__SCROLLPOS”] != null &&
Request[”__SCROLLPOS”] != String.Empty) {
int pos = Convert.ToInt32 (Request[”__SCROLLPOS”]);
Response.Write (”<body id=”theBody” ” +
“onscroll=”javascript:document.forms[0]” +
“.__SCROLLPOS.value = theBody.scrollTop;” ” +
“onload=”javascript:theBody.scrollTop=” +
pos + “;”>”);
}
else
Response.Write (”<body id=”theBody” ” +
“onscroll=”javascript:document.forms[0]” +
“.__SCROLLPOS.value = theBody.scrollTop;”<”);
%>

You also need to add this statement somewhere (anywhere) between the <l;form runat=”server”> and </form> tags:

<input type=”hidden” name=”__SCROLLPOS” value=”" />

And if you don’t have one already, add this directive to the top of the page:

<%@ Page Language=”C#” %>

What do these statements do? When the page is fetched outside a postback, the C# script emits a <body> tag containing an onscroll attribute that tracks the current scroll position and records it in the hidden <input> control, named __SCROLLPOS. If you execute a View/Source command, you’ll see something like this:

<body id=”theBody” onscroll=
“javascript:document.forms[0].__SCROLLPOS.value =
theBody.scrollTop;”>

When a postback occurs, the last scroll position accompanies the form’s postback data by virtue of having been assigned to the __SCROLLPOS control. The C# script responds by emitting a <body> tag, containing both an onscroll attribute and an onload attribute, that restores the page’s last scroll position:

<body id=”theBody” onscroll=
“javascript:document.forms[0].__SCROLLPOS.value =
theBody.scrollTop;”
onload=”javascript:theBody.scrollTop=615;”>

To see for yourself, run the page in Figure 2. The new and improved page retains its scroll position no matter which control you click.

<%@ Page Language=”C#” %>

<html>
<%
if (Request[”__SCROLLPOS”] != null &&
Request[”__SCROLLPOS”] != String.Empty) {
int pos = Convert.ToInt32 (Request[”__SCROLLPOS”]);
Response.Write (”<body id=”theBody” ” +
“onscroll=”javascript:document.forms[0]” +
“.__SCROLLPOS.value = theBody.scrollTop;” ”
“onload=”javascript:theBody.scrollTop=” +
pos + “;”>”);
}
else
Response.Write (”<body id=”theBody” ” +
“onscroll=”javascript:document.forms[0]” +
“.__SCROLLPOS.value = theBody.scrollTop;”>”);
%>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<l;br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
Hello, world!<br>Hello, world!<br>Hello, world!<br>
<form runat=”server”>
<input type=”hidden” name=”__SCROLLPOS” value=”" />
<asp:Button Text=”Test” RunAt=”server” /><br>
<asp:LinkButton Text=”Test” RunAt=”server” /><br>
<asp:Calendar RunAt=”server” />
</form>
</body>
</html>

Figure 2. This page retains its scroll position, even in the face of postbacks. Changes are highlighted in bold.

Now for the caveats. As presented, this code works with Internet Explorer but not Netscape Navigator. Because Navigator doesn’t support onscroll, you must take more extraordinary measures to retain the scroll position there. Also, the client-side script generated by my server-side script assumes the page contains only one form (or that the runat=”server” form is the first form on the page). This usually is a valid assumption for ASP.NET pages because a page can have only one runat=”server” form. But if your page contains multiple forms and the runat=”server” form isn’t the first one, you’ll need to assign the form an ID and replace document.forms[0] in my script with that ID.

Incidentally, you easily could wrap all that messy server-side script in a custom control and enable developers to eliminate unwanted scrolling by replacing a <body> tag with, say, an <asp:Body RunAt=”server”> tag and including the hidden <input> control in their forms. Because that’s simply too much fun for one person to contemplate, I’ll leave the implementation to you.

Finally, note that you also can eliminate unwanted scrolling by including this directive in an ASPX file:

<%@ Page SmartNavigation=”true” %>

This technique is far easier, but it works only with Internet Explorer 5.0 or higher and it’s incompatible with some Web controls.

Writing in Envision Basic and UniBasic code to use DataTel’s Computer-Aided Software Engineering (CASE) Tool, the Envision Tool Kit to create programs and write subroutines for DataTel solutions …

Envision provides a code generator that you can use to generate dynamic user-end processes… The Envision Tool Kit fits between the process stacks of the database management and the application software.

• The screen of the View Batch Process Status (VBS)
• View Single Batch Job Step (VBSD) displays error msgs.
• Re-Run a Procedure (UTRR)
• Application Definition (APD) use this screen to create new applications