A specific type of
Provider, the data provider connects your DotNetNuke code to a data store. In order to support upgrade capabilities, these files are named by version and the ones that are executed during upgrade are based on the previously installed version of the module. For example, if a module was being upgraded to version 2.0 and its previous version was 1.0. Any data provider files after 1.0 will be executed during the upgrade.
In order for a specific version of the file to run at installation time, each file must be declared in the DotNetNuke installer
manifest file within the Script component. It is also worth mentioning that a developer could, but should not, cause future named versions to execute during install by just including them in the manifest file.
Object Qualifier
The object qualifier, shown as {objectQualifier} in installation scripts, allows DotNetNuke data store items to be prefixed (for example, dnn_ before every stored procedure, view, table name).
While not its original intent, this can potentially allow multiple DotNetNuke installs to run within a single database.
Database Owner
The database owner, shown as {databaseOwner} in installation scripts...
SQL Data Provider
The only concrete data provider that ships with the core DotNetNuke framework is the this one, the SQL Data Provider. All DotNetNuke framework versions prior to 5.2 were capable of running on SQL Server 2000. As of 5.2, support for SQL Server 2000 was dropped and SQL 2005 and 2008 are required to use this SQL data provider.
For developers, one important thing to make note of is these files must be UTF-8 encoded.
xx.xx.xx.SqlDataProvider
These files are executed during module (or core) installation or upgrades. They primarily contain T-SQL statements with some named modifications for object qualifiers and database owners. The xx.xx.xx in the name represents the version associated with the script.
Uninstall.SqlDataProvider
This file should included all stored procedures, functions, views and tables created in the data store specific to your module and should drop these objects so that when your module is uninstall-ed there are no remnants of it in the data store. Developers should always check if an item exists prior to attempting to drop it.
These files follow the same rules (around object qualifier, database owner, encoding, etc.) that versioned SqlDataProviders follow.