The use and distribution terms for this software are contained in the file named LICENSE.RTF, which can be found in the root of this distribution. By using this software in any fashion, you are agreeing to be bound by the terms of this license.
This document applies to DBMethods version 1.0.3910.0 (also known as build 3910).
DBMethods version 1.0.3910 (also known as just build 3910) is the first release of the product. The first public beta was version 1.0.3504.
The Code Provisioning Compiler (cpc.exe) included in build 3910 of DBMethods is considered a Technology Preview. There are only a few features missing to turn it into a product-quality release. However, it is not a critical piece of DBMethods and is fairly functional if you do not, for example, rely on advanced options like delay signing of assemblies.
No. Although all code has been tested and written with the best intentions and for practical application in development and production environments, it is not a supported product. DBMethods is being released with source code and binaries for the general benefit of the .NET developer community. If you find issues or bugs, feel free to either report them to the author(s) or fix them. If you submit fixes, credit will be paid where it is due.
Yes, DBMethods can be installed side-by-side. That is, you can have more than one version of DBMethods installed on the same machine and your applications should continue to run against the versions they were built with. In fact, side-by-side is the only supported method of installation at the moment. There is no automatic upgrade available. The VS .NET custom tool that ships with DBMethods also runs side-by-side. You do not need to uninstall the beta build 3504 to run the release build 3910. Both will work fine on the same machine. You can uninstall the beta build as soon as you have moved all project references to the release build.
DBMethods has only been tested on Microsoft .NET Framework 1.0 and 1.1, which is a Microsoft implementation of the CLI currently targeting the Windows platforms. Since DBMethods addresses databases, it relies on availability of managed .NET Data Providers and these are not part of the CLI.
Code Provisioning, the technology behind DBMethods, however, has been tested and runs on the Windows XP build of Microsoft Shared Source CLI (SSCLI). Microsoft SSCLI is also commonly referred to by its code name of Rotor.
There are two ways to obtain the return value of a stored procedure. Using the first way, you add an out-parameter (by-reference) to your output method and decorate it with the SqlReturnValue attribute. How you choose to name the parameter is irrelevant. The second way is to add a SqlParameter object with its Direction set to ParameterDirection.ReturnValue once a SqlCommand object has been created, initialized and returned by an input method. The latter approach avoids having to create an output method just to receive the return value.
[Atif Aziz] During the initial design of DBMethods, I considered allowing output methods to have an integer return value that could be used to tunnel the return value of a stored procedure. The idea was finally dropped because there is no way to determine, using SQL Server metadata for example, whether a stored procedure has a return value or not. The safest assumption would therefore have been that all stored procedures return a value and this would force each input method to have an output method. Although SQL Server does allow stored procedures to return an integer value, their use is not very common. So in light of keeping things simple and that some databases may not even support the ParameterDirection of ReturnValue, return values were considered a special case that must be handled manually.
Although you cannot pass a transaction object directly to an input method, you can still get the effect by setting the Transaction property of the command object once it has been initialized and return by an input method. You can also provide an overload of the input method whose second parameter is a transaction object, right after the connection parameter. The overload can then call the base input method and assign the Transaction property of the command object returned by it.
Yes, you can overload input and output methods. The overloaded versions will most probably provide some processing before and/or after calling the base input and output methods. The overloads should not be decorated with the SqlMethod and SqlOutMethod attributes.
SQL Server stores the metadata for stored procedure parameters in the syscolumns table. The isoutparam column of syscolumns (or the documented IsOutParam property returned by COLUMNPROPERTY) specifies whether a parameter is input (0) or input/output (1). There is no distinction between input/output and output-only parameters. As a result, when the VS .NET custom tool and SqlMethods command-line tool generate data access methods, parameters marked as OUTPUT in a stored procedure's definition appear on input and output methods. A way to get around this problem is to provide an overload of the input method that sets the parameters that are logically output-only to empty values.
By default, the SqlMethods command-line tool uses Windows Authentication to connect to the database unless you use the /uid and /pwd switches to specify the credentials of a SQL user. If the SQL user has a blank password, then omit the /pwd switch.
The final release (version 1.0.3910) fully supports .NET Remoting by accommodating serializable objects and marshal-by-reference objects (objects that derive from System.MarshalByRefObject). DBMethods primarily deals with data access methods. If those methods are part of a type that can be marshaled by-reference, then .NET Remoting is supported in the usual way. Serializable types were not supported in previous beta builds (like v1.0.3504) primarily because the concrete type that is fabricated at runtime is not serializable. In the final release (build 3910), serializable types are fully supported, whether they depend on the Serializable attribute to provide the functionality or implement it themselves using custom serialization via the ISerializable interface.
The VS .NET custom tool and the SqlMethods command-line tool allow you to specify a base class for the types they generate. By default the type will inherit from System.Object, but you can specify MarshalByRefObject to have instances of the type remotable by reference. Unfortunately, serialization is not enabled for the code generated by these tools and must be worked in manually.
Yes, you can define and use delegates to call the data access methods asynchronously. Doing so however will present little or no benefit since all that those methods will be doing is creating and populating a command object or returning its output parameters. The real work is done during the execution of the command, which is what you probably want to make an asynchronous operation when needed.
The compiled assemblies that ship with build 3910 are compiled against .NET Framework 1.0. Therefore they contain static references to .NET Framework 1.0 assemblies in their respective manfiests. However, you can perfectly compile and run applications using DBMethods against .NET Framework 1.1. This works thanks to the unification of the .NET assemblies starting from version 1.1 of the .NET Framework and the runtime. So unless told to do otherwise via assembly binding redirection , the static references to .NET Framework 1.0 assemblies in DBMethods assembly manifests will be automatically upgraded and redirected to .NET Framework 1.1 assemblies (if that is what the host process is using).
In short, DBMethods supports .NET Framework 1.0 and 1.1.
The DBMethods custom tool that shipped with the original setup of DBMethods v1.0.3910 works with Microsoft Visual Studio .NET 2002 only. Microsoft Visual Studio .NET 2003 support was added later as a supplement package that can be downloaded separately . The supplement package does not include the original DBMethods v1.0.3910, which should be installed prior to the supplement for Microsoft Visual Studio .NET 2003.
No. The original public/private key pair that is used to sign the DBMethods assemblies does not ship in the installation package with the source code. However, you cannot assume that a strongly named assembly with the public key token b4cc74ffd1b38c91 identifies the author(s) of DBMethods or Skybow AG in any way.