bullet You are here:   The International Sybase User Group > Knowledge Center > Technical Journal > Issue 6, 2007
Become a Member | Login | Forgot Password?   Advertise With ISUG | Partner With ISUG
International Sybase User Group HeaderInternational Sybase User Group Header
Home
[ Login  |  Enhancements Process  |  Newsletter  |  Techcasts  |  Technical Journal  |  Sybase FAQ  |  Technical Resources ]
Partner Advertisement
Issue 6, 2007

A Preview of "Build Your Own ADO.NET 2.0 Class for ASE ... or Just About Anything Else"
The ADO.NET 2.0 API provides new classes to enable the developer to create common code to use with various providers. Wayne Smith walks us through the new world of possibilities.

With the ADO.NET 2.0 API a developer can create generic style applications to access ASE or other DBMSs. The following will provide steps on creating the project and getting started with the application code to implement this capability. The source code is located at Sybase Code Xchange at this URL: https://ase.codexchange.sybase.com/servlets/ProjectDocumentList?folderID=736, under “ADO.NET 2.0 Sample”.

Creating a .NET Project Create the project using Microsoft Visual Studio 2005 (MSDEV 2005 – MS.NET 2.0). Pick a name for the Solution (AseAdoUtils) and create the folder. This will be the folder for the .NET Solution, more or less a compilation of separate projects.

Start MSDEV 2005. From the menu select File->New->New Project. Then select Visual C#->Other Project Types->Visual Studio Solutions. Next, fill in Name as AseAdoUtils. The location in this case is C:\Stuff\PSE\ISUG\2007\ Web\AseAdoUtils_proj.

  1. Members: To continue reading click here.
  2. Non-Members: Join ISUG first and then download the article!
A Preview of "Enhancing Your Applications with ASE ADO.NET 2.0 Provider"
Paul Vero takes us an enlightening path toward enhancement as he leads us through the major features of the Sybase’s ASE ADO.NET 2.0 Provider

Sybase released the ASE ADO.NET 2.0 Provider in the Windows SDK 15.0 ESD#10 in September 2007. The significance of this release is the support of some ADO.NET 2.0 features such as Provider Factories and common base classes, making the developer's job easier and providing the ability to write more generic code when a shop's requirements involve multiple database vendors. Many users have already moved to the ADO.NET 2.0 API, and this release completes their plans to deploy applications to be used with ASP.NET and COM+, among other services, to access Sybase ASE. The initial release supports these features:

  1. Provider factories
  2. Common base classes
  3. Database metadata
  4. Provider statistics
  5. Bulk copy
  6. Batch update
  7. Asynchronous commands
  8. Extended pooling support to clear pools
  9. MARS (Multiple Active Result Sets)
  10. Connection String Lookup
  11. Connection Failover

In this article I'll cover the installation and configuration of the provider. Next, some features will be described in detail, with accompanying sample code to demonstrate the most commonly used features. The source code for this article will be available at the Sybase CodeXchange website:
https://ase.codexchange.sybase.com/servlets/ProjectDocumentView?documentID=2740&noNav=true. The samples will provide enough information to demonstrate the concept of the specific feature with enough detail to get you started so you can incorporate the functionality into your own applications.

  1. Members: To continue reading click here.
  2. Non-Members: Join ISUG first and then download the article!

A Preview of "Performance Considerations for Scalar UDFs"
In ASE 15.0.2, Sybase introduced scalar SQL User Defined Functions (UDF's). As many of you have been waiting a while for this capability, I am sure that you will be anxious to implement many of the functions you've wished you had over the years of application development. Jeff Tallman walks us through the new functionalities with a careful eye on performance considerations to allow you to get the most out of the way you code on the road ahead.

We all understand the benefits of increased maintainability, implementation simplicity and application portability that SQL UDF's provide. The intent of this article is to discuss the performance considerations along with a few recommendations that will ensure that your first attempts at SQL UDF's do not result in massive problems.

The syntax that is currently supported in 15.0.2 for scalar UDFs is: 

create function [ owner_name. ] function_name
( [ { @parameter_name [as] parameter_datatype
[ = default ] } [ ,...n ] ] )
returns return_datatype
[ with recompile] ]
as
[begin]
function_body
return scalar_expression
[end]

Not too much different than the syntax for create procedure command. However, there are some interesting nuances in execution and restrictions for use:

  1. When invoked, optional parameters that have a default value must be invoked using the keyword ‘default’ vs. simply not supplying the value
  2. The function owner must be specified (i.e. dbo.f() vs. just f())
  3. Any “write” DML operation such as insert, update and delete is not allowed
  4. All select statements must return their results to variables Select/into and other forms of explicit temp table creation are disallowed
  5. Execute immediate is disallowed

There are other restrictions not mentioned here – and as the focus of this article is on the performance considerations vs. usage, we won't delve too much into the above. These are only mentioned as they have an indirect bearing on some of the performance considerations. The considerations that we will be looking at in this article include:

  1. Correlated & uncorrelated functions
  2. Implicit “cursoring”
  3. Local data caching in SQL UDF's with recompile
  4. SQL UDF's in predicates
  5. Function-based Indices using SQL UDF&39;s
  6. Complex expressions & temp tables
  7. Performance diagnostics & SQL UDF's

We'll finish with a few recommendations for implementation.

  1. Members: To continue reading click here.
  2. Non-Members: Join ISUG first and then download the article!
A Preview of "Ringing the Changes for Change Management"
As modern database change management techniques for the Sybase DBA become more sophisticated, there is an inherent need for practitioners to be aware of the increasingly powerful tools available to them. Philip Rathle and Scott Walz of Embarcadero rifle through their DBA toolkit and sharpen up a few blades for us.

As mature and pervasive as Sybase ASE has become, nowhere does there appear to have emerged a universally-accepted system or standard that addresses the problem of database change management in an holistic fashion. DBA's sit at the center of a complex dance that touches many participants: data modelers, database developers, architects, business analysts, software developers and more.

At any given time, each database is physically instantiated across a number of different environments, each of which may contain any one of several versions of the same database. Furthermore, the design of a particular database is typically stored across a variety of locations and a multiplicity of tools, which may include a data modeling tool, a SQL development tool, a database administration tool, a database change management tool and so on.

Shepherding the stream
Accurately shepherding the stream of functional and technology change across all of these physical environments and design layer components can be a tremendous challenge. Oftentimes, the database change process has been (rightly or wrongly) patterned after the software change management process. This invariably leaves gaps, which DBA's usually fill with manual and ad hoc workarounds. The job gets done, however the process for achieving it is generally not optimal for the specifics of database applications. Moreover, it often comes at a cost of a gradually diverging design layer, as this layer lies for the most part outside of the DBA's purview.

  1. Members: To continue reading click here.
  2. Non-Members: Join ISUG first and then download the article!
A Preview of "Continuity Counts – Business Continuity Management Comes of Age"
For developers, DBAs and a variety of other members of the software engineering spectrum, Business Continuity Management may just appear to be a case of the board room members sticking their noses a little to far into the running of the organisation's day-to-day business – and that includes the IT function. But it's worth some exploration and examination, at least that way you'll know what the ‘suits’ upstairs are thinking, or at least what they are using to help try and think for them!

So what is BCM?
A classic definition reads something like this: BCM is an interdisciplinary peer mentoring methodology used to create and validate a practiced logistical plan for how an organisation will recover and restore partially or completely interrupted critical function(s) within a predetermined time after a disaster or extended disruption.

Huh? What was all that? OK yeah, this is also popularly referred to as disaster recovery. But it is an intelligent business that treats disaster recovery not as an IT issue, but as a ‘whole of the business’ issue. In return, it is also an intelligent business that treats IT as central and integral to the whole business. This, unfortunately, is all too rare the case.

  1. Members: To continue reading click here.
  2. Non-Members: Join ISUG first and then download the article!
A Preview of "PowerBuilder 11's .NET Interoperability"
John Strano explains how PowerBuilder 11 deploys entire applications as .NET Windows Form or Web Form applications and deploys individual components as .NET Assemblies and as .NET Web Services. Version 11 consumes resources of the default .NET framework as well as resources of custom developerdefined .NET resources. Non-PowerBuilder .NET solutions can interoperate with, and take advantage of, the unparalleled productivity of PowerBuilder. In short, PowerBuilder 11 creates as well as consumes .NET resources.

Once PowerBuilder 11 has deployed an application or a component as .NET, the developer can begin taking advantage of external .NET resources on a scripted basis through PowerScript enhancements. The scripted .NET interoperability in PowerBuilder 11 is predicated on a new conditional compilation feature. Conditional compilation allows declarations, references and calls, etc. that are meant for .NET interop to be declared within preprocessor blocks of code. These preprocessor blocks are constructs similar to IF statements. If the developer specifies that these #IF/THEN/#ELSE/#ELSEIF blocks are only for .NET runtime execution, they're ignored by PowerBuilder's Win32 compiler.

Conditional compilation
The developer doesn't need to commit the syntax of the new constructs to memory or lose his or her train of thought switching from the IDE to a help file. A productive addition to the PowerScript editor enables the developer to quickly paste in the desired flavor of .NET #IF statement.

The preprocessor variants allow the developer to provide for a blanket .NET deployment condition and if they wish, to drill down to specific flavors of that deployment like WinForms, WebForm, Web Services, etc.

  1. Members: To continue reading click here.
  2. Non-Members: Join ISUG first and then download the article!

[Click for PDF]

Search isug.com
Google Custom Search

Resources

General:

Tools:

Miscellaneous:

External Links:

ISUG Partner
Novalys Website