Introduction à ADO.NET en C#

ADO.NET est un ensemble de composants présents de base dans le framework .NET permettant l’accès et la gestion de données situées sur une base de données relationnelle (SQL Server, Oracle, etc…) ou non. ADO.NET est une évolution de ADO (ActiveX Data Objects).

Les classes ADO.NET peuvent être divisées en 2 parties. Les classes permettant de se connecter à la source de données et les classes utilisées pour gérer les données.

La connexion à la source de données

Pour se connecter à une base de données via ADO.NET un Data Provider (fournisseur de données) correspondant à la base de données utilisée. Ainsi le Data Provider de SQL Server est optimisé pour fonctionner avec les bases de données SQL Server, idem pour le Data Provider Oracle. Tous les Data Providers sont dérivés d’une seule et même classe, ils implémentent les mêmes méthodes, propriétés, et fonctionnent donc de la même manière. Dans certains cas, les Data Providers peuvent implémenter des fonctionnalités spécifiques à la base de données utilisée (exemple des requêtes XML pour SQL Server).

Empêcher la connexion automatique de l’utilisateur après sa création avec un CreateUserWizard en ASP.NET

Visual Studio propose un contrôle permettant la création d’utilisateurs dans la base de données : CreateUserWizard.

Ce contrôle est un gain de temps non négligeable, mais lorsque l’on veut sortir du cadre classique de l’inscription de membres, il faut chercher un peu pour obtenir ce que l’on souhaite.

Dans le cadre d’un panneau d’administration, il peut être utile de permettre la création d’utilisateurs par les administrateurs. Cependant le comportement par défaut du CreateUserWizard est d’automatiquement connecter l’utilisateur courant avec le compte qui vient juste d’être créé, ce qui est embêtant dans le cadre d’un panneau d’administration.

Modification des données grâce à Linq To SQL et aux procédures stockées

Cet article est la suite de l’article Lier une base de données et un GridView avec Linq To SQL.

Ici il est question des procédures stockées. Comme vous avez pu le remarquer dans l’article précédent, nous n’avons écrit aucune ligne de code pour construire des requêtes SQL, tout s’est fait automatiquement.

Pourquoi s’embêter à écrire du code alors ?

Les procédures stockées sont enregistrées et pré-compilées dans la base de données SQL Server, ce qui est un gain de **rapidité **et de performance. Toutes les procédures stockées sont enregistrées au même endroit dans la base de données ce qui simplifie grandement leurs éditions. Dernier atout qui n’est pas à négliger, la sécurité. En effet toutes les modifications de la base de données se font via les procédures stockées. A aucun moment l’utilisateur n’a un accès direct à la table.

Lier une base de données et un ASPxGridView avec Linq To SQL

Suite de mes articles sur les technologies .NET et DXperience. Le but est ici de lier efficacement une base de données à un ASPxGridView grâce à **Linq To SQL **graphiquement.

Petite précision, mon OS et mon IDE (Visual studio) sont en anglais, si le votre est en français, vous n’aurez pas exactement les mêmes mots, mais vous vous y retrouverez sans problème.

Voici les étapes et quelques explications concernant le screencast.

‘Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Je continue mes articles sur l’ASP.NET et sur DXperience.

Dans le “Demo Center” de Dxperience (logiciel qui présente des exemples d’utilisation de cet outil). Dans la partie ASP.NET -> XtraReports, les exemples peuvent ne pas fonctionner si votre système est en 64 bits.

L’erreur obtenue est :

Microsoft.Jet.OLEDB.4.0′ provider is not registered on the local machine

Pour remédier au problème, rendez-vous dans la console de gestion du serveur IIS, soit dans Server Manager > Roles > Web Server (IIS) > Internet Information Services (IIS) Manager pour Windows Server ou dans Computer Management > Services and Applications pour Windows Vista ou Seven.