1
Développement des Applications des
Bases de Données
Chapitre 6
2
Survol
SQL dans les codes d’application
SQL imbriqué
Curseurs
SQL dynamique
JDBC
SQLJ
Procédures stockées
3
SQL dans les codes d’Application
Les commandes SQL peuvent être appelées à partir
d’un programme d’application («langage hôte» --
C++, Java, etc).
Les instructions SQL peuvent référer à des variables du
langage hôte (y compris des variables utilisées pour
retourner les statuts).
On doit inclure une instruction pour connecter à la base de
données appropriée.
Deux approches d’intégration existent:
Instructions SQL imbriquées dans le langage hôte
Embedded SQL », SQLJ)
Création d’une API spéciale pour appeler les commandes
SQL (JDBC)
4
SQL dans les codes d’Application (Suite)
Les relations SQL sont des (multi)ensembles de tuples
qui n’imposent aucune limite a priori sur le nombre de
tuples. Les langages de programmation traditionnels
(C, C++, etc.) n’ont pas une telle structure de données.
Ce problème est appelé inadaptation d’impédance
impedance mismatch ») .
SQL supporte un mécanisme appelé curseur pour
résoudre ce problème.
Un curseur est un élément additionnel de SQL qui
comble le fossé causé par l’inadaptation d’impédance.
5
SQL Imbriqué: Variables
EXEC SQL BEGIN DECLARE SECTION
char c_sname[20];
long c_sid;
short c_rating;
float c_age;
EXEC SQL END DECLARE SECTION
Deux problèmes avec les variables:
correspondance des types (solution: casting/correspondance
explicite)
inadaptation d’impédance (solution: le mécanisme de curseur)
Deux variables spéciales d’“erreur” (une au moins doit être
déclarée):
SQLCODE (long, est négative si une erreur est apparue)
SQLSTATE (char[6], codes prédéfinies pour des erreurs
usuelles)
1 / 26 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !