Difference between revisions of "General:Concepts"
m (→General structure of the tool) |
m (→Normalisation) |
||
| Line 94: | Line 94: | ||
It is composed of a core part, common to all DBMSs used (template engine, graphic display, tables, ...) and a specific module for each RDBMS.<br> | It is composed of a core part, common to all DBMSs used (template engine, graphic display, tables, ...) and a specific module for each RDBMS.<br> | ||
| − | == | + | ==Standardization== |
| − | + | One of the bases of “homogeneity” is standardization and genericity.<br> | |
| − | === | + | ===Naming convention=== |
| − | ==== | + | ====Trees==== |
| − | + | General tree structures (on SQWareCentral) : | |
<pre> | <pre> | ||
| − | …/dbSQWare/SQWareProduction/… => | + | …/dbSQWare/SQWareProduction/… => SQWareProduction module tree. |
| − | …/dbSQWare/SQWareRepository/… => | + | …/dbSQWare/SQWareRepository/… => SQWareRepository module tree. |
| − | …/dbSQWare/SQWareCentral/… => | + | …/dbSQWare/SQWareCentral/… => SQWareCentral module tree. |
| − | …/dbSQWare/SQWareWeb/… => | + | …/dbSQWare/SQWareWeb/… => SQWareWeb module tree. |
</pre> | </pre> | ||
<br> | <br> | ||
| − | + | Then for the level below the modules there is a directory « generic » containing everything that is common to all RDBMS and one directory for each supported RDBMS.<br> | |
| − | + | This is what it looks like : | |
<pre> | <pre> | ||
| − | cassandra => | + | cassandra => specific for Cassandra |
| − | db2 => | + | db2 => specific for DB2 |
| − | generic => | + | generic => generic to all engines |
| − | ingres => | + | ingres => specific for Ingres |
| − | mongodb => | + | mongodb => specific for MongoDB |
| − | mssql => | + | mssql => specific for MsSql |
| − | mysql => | + | mysql => specific for MySQL |
| − | oracle => | + | oracle => specific for Oracle |
| − | postgres => | + | postgres => specific for PostgreSQL |
| − | sybase => | + | sybase => specific for Sybase ASE |
| − | sybrep => | + | sybrep => specific for Sybase RS |
| − | teradata => | + | teradata => specific for teradata |
| − | adabas => | + | adabas => specific for adabas |
</pre> | </pre> | ||
<br> | <br> | ||
| − | + | Then, for trees containing scripts, you will find directories like the following ; The directories of form *_cust are dedicated to customizing your environment, as much as possible, only touch the scripts and configuration files of these trees, This will make it easier for you to update the tool (unless there is a specific bug, there is no reason to touch the standard trees if you follow the customization recommendations).<br> | |
| − | + | Contents of directories : | |
<pre> | <pre> | ||
| − | bin => scripts | + | bin => standard scripts |
| − | bin_cust => scripts | + | bin_cust => custom scripts for your environment |
| − | etc => | + | etc => standard configuration files (global variables) |
| − | etc_cust => | + | etc_cust => custom configuration files (overload the standards) |
| − | help => | + | help => standard help files |
| − | help_cust => | + | help_cust => custom help files for your environment |
| − | lib => | + | lib => standard shell function libraries |
| − | lib_cust => | + | lib_cust => custom shell function libraries (overload the standards) |
| − | tools => scripts | + | tools => standard scripts used occasionally |
| − | tools_cust => scripts | + | tools_cust => standard scripts used occasionally for your environment |
| − | menu => menus (shell) | + | menu => standard menus (shell) |
| − | menu_cust => menus | + | menu_cust => custom menus for your environment |
</pre> | </pre> | ||
<br> | <br> | ||
| − | + | So here, for example, is what it looks like for SQWareProduction Oracle and Generic: | |
<pre> | <pre> | ||
SQWareProduction/oracle | SQWareProduction/oracle | ||
| Line 170: | Line 170: | ||
====Fichiers (arborescence scripts)==== | ====Fichiers (arborescence scripts)==== | ||
| − | + | Most files are named with a prefix of the form : | |
<pre> | <pre> | ||
| − | sqwora_* => | + | sqwora_* => for Oracle |
| − | sqwsyb_* => | + | sqwsyb_* => for Sybase ASE |
| − | sqwrs_* => | + | sqwrs_* => for Sybase RS |
| − | sqwmys_* => | + | sqwmys_* => for Mysql |
| − | sqwmsq_* => | + | sqwmsq_* => for Mssql |
| − | sqwdb2_* => | + | sqwdb2_* => for DB2 |
| − | sqwpg_* => | + | sqwpg_* => for PostgreSQL |
| − | sqwter_* => | + | sqwter_* => for Teradata |
| − | sqwcas_* => | + | sqwcas_* => for Cassandra |
| − | sqwada_* => | + | sqwada_* => for Adabas |
| − | sqwing_* => | + | sqwing_* => for Ingres |
| − | sqwgen_* => | + | sqwgen_* => for generics one |
| − | sqwctl_* => | + | sqwctl_* => for those from the module SQWareCentral |
</pre> | </pre> | ||
<br> | <br> | ||
| − | + | Most files are named with a suffix of the form : | |
<pre> | <pre> | ||
| − | *.ksh => | + | *.ksh => for scripts shell |
| − | *.cfg => | + | *.cfg => for configuration files (global variables) |
| − | *.lib => | + | *.lib => for shell function libraries |
| − | *.hlp => | + | *.hlp => for help files |
</pre> | </pre> | ||
<br> | <br> | ||
Revision as of 18:29, 20 March 2025
Generality
Limitations of this section
this section
Cette section does not claim to handle all possible configuration cases of dbSQWare but will allow you to understand the general structure of the tool, interconnection between modules,
the principles of personalization, …
For any kind of information, web site
(Visitez le wiki dbSQWare français, WikiFr)
Before running into the installation, please read the section « Base Installation », this will allow you to make a standard installation of dbSQWare.
dbSQWare, what is it ?
dbSQWare allows you to unite the use of databases Oracle, Sybase, SqlServer, MySQL, DB2, PostgreSQL, MongoDB, Cassandra, … thanks to a common and homogeneous base. The design of this platform provides great flexibility of use, of personalization and a unified approach to the exploitation and rendering of indicators on all types of DBMS managed by the tool.
It is neither an administration tool nor a monitoring tool (not a monitoring tool but a complement to it).
The product is intended (for its scripting part) for environments Unix/Linux only because it is essentially written in shell ksh and sql (MsSql too is fully managed from depuis unix thanks to a FreeTds connection, for more information http://www.freetds.org/). The web part, for its part, is written in PHP and javascript (jQuery).
For DBMS other than MsSql and installed on a Windows host, many functionalities (but not all) are accessible with a distant SQL connection (for the scripts supporting that).
List DBMs supported at this time :
- Oracle
- Sybase (ASE and RS)
- MySQL
- MsSql
- MongoDB
- DB2
- PostgreSQL
- Teradata
- Cassandra
- Adabas
- Ingres
A search for “Homogeneity”
In use :
- Consistent use, whatever the DBMS
- Easy adaptation using configuration files and/or passing arguments
- A single version of the tool for the entire fleet (synchronization by rsync)
- The scripts adapt to the version of the DBMS processed (a single script for an action. Example : the script for oracle indicators supports from v7 to 19c multitenant architecture)
- Launch without arguments
- Online help (arguments and examples)
- Dry run mode for validate the syntax (flag -Exec for the execution)
In the development and evolutions :
- Homogeneous design for all DBMS
- Code standardization (names, functions, structures, parsing of arguments, online help, …)
- Generic multi-engine libraries
- Modification of behavior by overloading libraries
- Set of standard shell libraries that can be integrated into custom scripts
General structure of the tool
dbSQWare is composed of four complementary modules.
SQWareProduction is the local exploitation module (or remotely for 80% of the functionalities) of the DBMs. It makes possible to manage the operations in the broad sense of DBMS :
- Backup
- Restorations
- Statistics
- Alerts reporting
- Job launch encapsulation
- Running unix commands in parallel
- ...
This module gather also a certain number of indicators which are uploaded to the repository of databases SQWareRepository. this module is made of a part for each managed DBMS and a core part including a set of settings and functions generic to all DBMS. the scripts are all written according to the same development standard (parsing of arguments, online help, mail on error, ascent of indicators into SQWareRepository, …).
SQWareRepository is the module for the management of the repository and the indicators in the database :
It allows you to manage the repository as well as the indicators stored in databases.
It's a MySQL database (>= 5.6) or MariaDB (>= 10.1), with generic tables as well as specific tables depending on the DBMS processed.
SQWareCentral is the central module of the tool. It allows all database servers to be managed from this single central point :
- Centralized indicator collection,
- Deployment of SQWareProduction via rsync,
- Full-text search in repositories,
- Simplified SSH connection to different instances in the repositories,
- CMDB file generation,
- Centralized indicator check.
This module is based, among other things, on the repository, SQWareRepository (dynamic generation of lists of instances to be processed, …).
It is composed of a core part, common to all DBMSs used and a specific module for each RDBMS (Oracle, Sybase, MsSql, MySQL, DB2, PostgreSQL, MongoDB, Cassandra, …).
Typically, the central point installation is done on a Rocky Linux VM, currently on release 9.5, 64 bits (2 vCPU and 4 Go RAM), or RHEL 9.5.
SQWareWeb is the web graphic rendering module for indicators :
It works with apache 2.x and is written in PHP (supported from 7.4 to 8.x), javascript (jQuery).
It allows the presentation of indicators and capacity planning in multiples forms :
- Graphics (javascript)
- Tables (with sorting, filtering and formatting locally on the browser)
- Exports Excel, ...
- ...
It is based entirely on the data contained in the database repository SQWareRepository.
No connection to client databases, the interface is only used for restoring indicators and configuring the repository.
The restitutions are presented in roughly the same way regardless of the RDBMS (except for its specificities), which makes navigation more pleasant and easier.
It is composed of a core part, common to all DBMSs used (template engine, graphic display, tables, ...) and a specific module for each RDBMS.
Standardization
One of the bases of “homogeneity” is standardization and genericity.
Naming convention
Trees
General tree structures (on SQWareCentral) :
…/dbSQWare/SQWareProduction/… => SQWareProduction module tree. …/dbSQWare/SQWareRepository/… => SQWareRepository module tree. …/dbSQWare/SQWareCentral/… => SQWareCentral module tree. …/dbSQWare/SQWareWeb/… => SQWareWeb module tree.
Then for the level below the modules there is a directory « generic » containing everything that is common to all RDBMS and one directory for each supported RDBMS.
This is what it looks like :
cassandra => specific for Cassandra db2 => specific for DB2 generic => generic to all engines ingres => specific for Ingres mongodb => specific for MongoDB mssql => specific for MsSql mysql => specific for MySQL oracle => specific for Oracle postgres => specific for PostgreSQL sybase => specific for Sybase ASE sybrep => specific for Sybase RS teradata => specific for teradata adabas => specific for adabas
Then, for trees containing scripts, you will find directories like the following ; The directories of form *_cust are dedicated to customizing your environment, as much as possible, only touch the scripts and configuration files of these trees, This will make it easier for you to update the tool (unless there is a specific bug, there is no reason to touch the standard trees if you follow the customization recommendations).
Contents of directories :
bin => standard scripts bin_cust => custom scripts for your environment etc => standard configuration files (global variables) etc_cust => custom configuration files (overload the standards) help => standard help files help_cust => custom help files for your environment lib => standard shell function libraries lib_cust => custom shell function libraries (overload the standards) tools => standard scripts used occasionally tools_cust => standard scripts used occasionally for your environment menu => standard menus (shell) menu_cust => custom menus for your environment
So here, for example, is what it looks like for SQWareProduction Oracle and Generic:
SQWareProduction/oracle SQWareProduction/oracle/bin SQWareProduction/oracle/bin_cust SQWareProduction/oracle/etc SQWareProduction/oracle/etc_cust SQWareProduction/oracle/help SQWareProduction/oracle/help_cust SQWareProduction/oracle/lib SQWareProduction/oracle/lib_cust SQWareProduction/oracle/menu SQWareProduction/oracle/menu_cust SQWareProduction/oracle/tools SQWareProduction/oracle/tools_cust SQWareProduction/generic SQWareProduction/generic/bin SQWareProduction/generic/bin_cust SQWareProduction/generic/etc SQWareProduction/generic/etc_cust SQWareProduction/generic/lib SQWareProduction/generic/lib_cust SQWareProduction/generic/tools SQWareProduction/generic/tools_cust
Fichiers (arborescence scripts)
Most files are named with a prefix of the form :
sqwora_* => for Oracle sqwsyb_* => for Sybase ASE sqwrs_* => for Sybase RS sqwmys_* => for Mysql sqwmsq_* => for Mssql sqwdb2_* => for DB2 sqwpg_* => for PostgreSQL sqwter_* => for Teradata sqwcas_* => for Cassandra sqwada_* => for Adabas sqwing_* => for Ingres sqwgen_* => for generics one sqwctl_* => for those from the module SQWareCentral
Most files are named with a suffix of the form :
*.ksh => for scripts shell *.cfg => for configuration files (global variables) *.lib => for shell function libraries *.hlp => for help files
Fichiers (arborescence web)
La majorité des fichiers sont nommés avec un suffixe de la forme :
*.php => pour les scripts PHP *.js => pour les scripts javascript *.chart => pour les fichiers de paramétrage des graphiques *.table => pour les fichiers de paramétrage des tableaux
Contenu des scripts shell
En général, la convention suivie dans les scripts shell est la suivante :
gvsqw_*{} => variable globale initialisée par l’environnement et/ou une librairie générique
lvsqw_*{} => variable locale initialisée par le script et/ou une librairie spécifique
gfsqw_*{} => fonction définie par une librairie générique
lfsqw_*{} => fonction définie par le script et/ou une librairie spécifique
Objets bdd (SQWareRepository)
Les objets préfixés par tsqw_% or isqw_% sont génériques à tous les moteurs. Les objets préfixés par tsqwXXX_% or isqwXXX_% sont spécifiques pour un SGBD particulier (exemple : tsqwcas_% or isqwcas_% pour Cassandra).
Noms des objets génériques :
tsqw_% => pour les tables isqw_% => pour les indexes isqw_%_u => pour les indexes uniques isqw_%_pk => pour les primary keys
Noms des objets spécifiques :
tsqwXXX_% => pour les tables isqwXXX_% => pour les indexes isqwXXX_%_u => pour les indexes uniques isqwXXX_%_pk => pour les primary keys
Exemple du spécifique pour Cassandra :
tsqwcas_% => pour les tables isqwcas_% => pour les indexes isqwcas_%_u => pour les indexes uniques isqwcas_%_pk => pour les primary keys
Principe de surcharge
Attention, cette section est une partie essentielle pour paramétrer dbSQWare sans remettre en cause les prochains patches/upgrades. Comme expliqué dans la section précédente, il ne faut pas toucher aux fichiers des arborescences standards, mais utiliser les répertoires de type *_cust pour faire votre customisation.
Lors d’un patch/upgrade, on extrait l’archive dbSQWare_full_latest.tgz par-dessus l’arborescence installée, ce qui écrase les fichiers standards avec la nouvelle version mais conserve vos customisations !
Le principe de base de la surcharge est de créer un fichier de même nom que dans l’arborescence (XXX) standard dans l’arborescence (XXX_cust) et d’y redéclarer la/les variables/librairies nécessaire(s).
Ne déclarez que le strict nécessaire pour le fonctionnement sur votre environnement (inutile de tout déclarer comme pour une configuration bdd).
Personnalisation des variables
Le fichier essentiellement mis à jour pour les variables est sqwgen_GlobalVar.cfg, nous le prendrons donc comme exemple.
Le principe suivant se base sur $gvsqw_GenPath qui représente le path du script exécuté et sur ${gvsqw_RdbmsRoot} qui représente le trigramme (en minuscule) du SGBD sur lequel tourne le script et $gvsqw_RdbmsType, le répertoire spécifique du SGBD. Voir le paragraphe sur les règles de nommage pour les noms de fichiers réels.
Principe général du source en cascade (si les fichiers existent, 6 niveaux) :
# Fichier generic standard => pour tout le parc
$gvsqw_GenPath/../../generic/etc/sqwgen_GlobalVar.cfg
# Fichier generic custom => pour tout le parc
$gvsqw_GenPath/../../generic/etc_cust/sqwgen_GlobalVar.cfg
# Pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqwgen_GlobalVar.cfg
# Fichier spécifique sgbd standard => pour tout le parc
$gvsqw_GenPath/../../$gvsqw_RdbmsType/etc/sqw${gvsqw_RdbmsRoot}_GlobalVar.cfg
# Fichier spécifique sgbd custom => pour tout le parc
$gvsqw_GenPath/../../$gvsqw_RdbmsType/etc_cust/sqw${gvsqw_RdbmsRoot}_GlobalVar.cfg
# Fichier spécifique sgbd pour une machine non normalisée => spécifique à la machine
$HOME/sqwConfig/sqw${gvsqw_RdbmsRoot}_GlobalVar.cfg
Exemple pour SQWareProduction Oracle installé dans le $HOME :
# Fichier generic standard => pour tout le parc $HOME/SQWareProduction/../../generic/etc/sqwgen_GlobalVar.cfg # Fichier generic custom => pour tout le parc $HOME/SQWareProduction/../../generic/etc_cust/sqwgen_GlobalVar.cfg # Pour une machine non normalisée => spécifique à la machine $HOME/sqwConfig/sqwgen_GlobalVar.cfg # Fichier spécifique sgbd standard => pour tout le parc $HOME/SQWareProduction/../../oracle/etc/sqwora_GlobalVar.cfg # Fichier spécifique sgbd custom => pour tout le parc $HOME/SQWareProduction/../../oracle/etc_cust/sqwora_GlobalVar.cfg # Fichier spécifique sgbd pour une machine non normalisée => spécifique à la machine $HOME/sqwConfig/sqwora_GlobalVar.cfg
Personnalisation des fonctions shell
En principe, sauf cas d’utilisation avancé de dbSQWare, vous n’avez pas besoin de personnaliser les fonctions, la surcharge de variables ou le passage d’options est suffisant dans la grosse majorité des cas (plus de 99%).
Attention, la customisation de fonction demande un minimum de compétences en shell et une analyse d’impact sur le fonctionnement futur des scripts. Nous vous conseillons de vous faire assister par le support, au moins pour la première fois.
La majorité des scripts des arborescences …/bin/ sourcent (grâce à la fonction gfsqw_SourceOverLoadLibs) les librairies du même nom que le script, en remplaçant .ksh par .lib (exemple : yyy.ksh va sourcer yyy.lib).
Dans l’explication suivante des sources en cascade de librairies, voici à quoi correspondent les variables :
gvsqw_GenPath => path du script exécuté lvsqw_Lib => librairie que l’on souhaite charger (exemple sqwora_Global.lib) lvsqw_LibGen => nom générique, on remplace dans lvsqw_Lib le trigramme spécifique au SGBD par gen (exemple sqwgen_Global.lib)
Principe général du source en cascade (si les fichiers existent, 10 niveaux) :
# Librairie generic standard => pour tout le parc $gvsqw_GenPath/../../generic/lib/$lvsqw_LibGen # Librairie generic custom => pour tout le parc $gvsqw_GenPath/../../generic/lib_cust/$lvsqw_LibGen # Librairie spécifique sgbd standard => pour tout le parc $gvsqw_GenPath/../lib/$lvsqw_LibGen # Librairie spécifique sgbd custom => pour tout le parc $gvsqw_GenPath/../lib_cust/$lvsqw_LibGen # Pour une machine non normalisée => spécifique à la machine $HOME/sqwConfig/$lvsqw_LibGen # Librairie generic standard => pour tout le parc $gvsqw_GenPath/../../generic/lib/$lvsqw_Lib # Librairie generic custom => pour tout le parc $gvsqw_GenPath/../../generic/lib_cust/$lvsqw_Lib # Librairie spécifique sgbd standard => pour tout le parc $gvsqw_GenPath/../lib/$lvsqw_Lib # Librairie spécifique sgbd custom => pour tout le parc $gvsqw_GenPath/../lib_cust/$lvsqw_Lib # Pour une machine non normalisée => spécifique à la machine $HOME/sqwConfig/$lvsqw_Lib
Exemple pour sqwora_ParallelRun.ksh de SQWareProduction Oracle installé dans le $HOME :
# Librairie generic standard => pour tout le parc $HOME/SQWareProduction/../../generic/lib/sqwgen_ParallelRun.lib # Librairie generic custom => pour tout le parc $HOME/SQWareProduction/../../generic/lib_cust/sqwgen_ParallelRun.lib # Librairie spécifique sgbd standard => pour tout le parc $HOME/SQWareProduction/../lib/sqwgen_ParallelRun.lib # Librairie spécifique sgbd custom => pour tout le parc $HOME/SQWareProduction/../lib_cust/sqwgen_ParallelRun.lib # Pour une machine non normalisée => spécifique à la machine $HOME/sqwConfig/sqwgen_ParallelRun.lib # Librairie generic standard => pour tout le parc $HOME/SQWareProduction/../../generic/lib/sqwora_ParallelRun.lib # Librairie generic custom => pour tout le parc $HOME/SQWareProduction/../../generic/lib_cust/sqwora_ParallelRun.lib # Librairie spécifique sgbd standard => pour tout le parc $HOME/SQWareProduction/../lib/sqwora_ParallelRun.lib # Librairie spécifique sgbd custom => pour tout le parc $HOME/SQWareProduction/../lib_cust/sqwora_ParallelRun.lib # Pour une machine non normalisée => spécifique à la machine $HOME/sqwConfig/sqwora_ParallelRun.lib
Interopérabilité des modules
Communications entre les modules
Depuis SQWareProduction
SQWareProduction est le seul module se connectant directement aux bases de données clientes.
Il permet ensuite notamment de remonter un certain nombre d’indicateurs dans SQWareRepository (en passant par un tampon local).
C'est SQWareCentral qui vient chercher les données dans le tampon de SQWareProduction par rsync.
Depuis SQWareRepository
SQWareRepository étant une database MySQL (>= 5.6) ou MariaDB (>= 10.1), aucun flux n’est à son initiative.
Depuis SQWareCentral
SQWareCentral se connecte à SQWareRepository pour générer les listes d’instances à traiter.
Il permet de lancer des commandes SQWareProduction au travers d’une connexion ssh.
Il permet également le déploiement des scripts SQWareProduction ainsi que la récupération des traces SQWareProduction par rsync.
Pré-requis :
- Package rsync sur le point central et les clients SQWareProduction
- Flux ssh vers les clients SQWareProduction (TCP port 22 vers les clients SQWareProduction)
- Flux vers le repo MySQL/MariaDB (en général les deux modules sont sur la même machine)
Depuis SQWareWeb
SQWareWeb se connecte à SQWareRepository qui contient les indicateurs (aucune connexion vers les bases clientes).
Pré-requis :
- Packages httpd php php-pdo php-mysql
- Flux vers le repo MySQL/MariaDB (en général les deux modules sont sur la même machine)
Matrice de flux
Cette section ne couvre pas tous les cas possibles, mais doit vous permettre de faire ouvrir les flux nécessaires en cas de présence de FW.
| Type | Nombre | Source | Destination | Port (courant) | Commentaire |
|---|---|---|---|---|---|
| Toujours | x | SQWareCentral | SQWareProduction | 22 | Rsync sources + exec à distance |
| Spécifique Ora | x | SQWareProduction sur CentralHost |
bdd Oracle | 1521 | Lorsque l'on souhaite collecter les rapports AWR depuis le point central. Autant de fois qu'il y a de bdd Oracle. |
| Spécifique Msq | x | SQWareProduction sur CentralHost |
bdd MsSql | 1433 | Lorsque l'on souhaite gérer tous les MsSql depuis le point central. Peut-être aussi installé sur une autre machine que le pont central. |
| ... | x | CentralHost | toute bdd | 1521, 1433, 5432, ... | Lorsque l'on souhaite accéder aux instances depuis le point central en SQL. Ce besoin est pur DBA et non nécessaire à dbSQWare. |
| Distribué | 1 | SQWareCentral | SQWareRepository | 3306 | Quand la base MySQL/MariaDB du repo n'est pas sur le point central (rare) |
| Distribué | 1 | SQWareWeb | SQWareRepository | 3306 | Quand la base MySQL/MariaDB du repo n'est pas sur le point central (rare) ou que SQWareWeb n'est pas sur le point central (rare) |
Liens utiles
Voici les liens utiles pour dbSQWare:
- http://www.dbsqware.com/ => Site principal
- http://webdba.dbsqware.com/ => Démonstration du module SQWareWeb
- http://wiki.dbsqware.com => Wiki anglais (complet)
- http://wikifr.dbsqware.com => Wiki d'install en français
- http://blog.dbsqware.com => Blog SGBD
Rejoignez le groupe dbSQWare sur viadéo:
http://www.viadeo.com/groups/?containerId=002dcbr792acawk
Rejoignez le groupe dbSQWare sur Linkedin:
http://www.linkedin.com/groups?gid=3683269
