Recommend Me


Lundi 20 février 2006

SapDB

(Linux Magazine France n°49 - Avril 2003)

SAP DB est un SGBD largement moins connu que PostgreSQL ou MySQL. Ceci est peut-être dû au fait que cette base n’est passée sous licence GPL qu’en Avril 2001 avec la version 7.2. Nous ne pouvons que saluer une telle initiative même si elle semble un peu tardive pour venir faire de l’ombre aux autres SGBD du monde libre. De plus SAP DB n’est pas particulièrement facile d’accès et demande de passer de longues heures à lire de la documentation au risque d’attraper un gros mal de tête.

Troll

SAP DB demande plus de rigueur qu’une base comme MySQL ou Postgres. Nous sommes plus proche d’un Oracle ou d’un DB2. Je vais donc me contenter de présenter les choses de manière très simple sans rentrer dans le détail de la compilation ou du tunning de la base. Nous allons voir comment installer SAP DB, créer notre première base et y accéder par ODBC.

Installation

Pour installer SAP DB j’ai utilisé un PIV 1.6GHz équipé de 512Mo de RAM et tournant sous Debian “sid”. L’installation utilise 157Mo de disque en comptant que j’ai une base dont la taille frise le ridicule ;). Ceci est largement suffisant, sachant que la configuration minimale requise demande 128Mo de mémoire et 100Mo de disque dur (sans la base). Sachez aussi que vous aurez besoin de la glibc2.1 et de la libpthread0.8. Notez enfin que pour installer SAP DB il faut être root.

Sur le site de SAP DB (www.sapdb.org) vous trouverez les archives dont vous avez besoin pour l’installation. Comme vous pourrez le constater la dernière version stable pour Linux est la 7.3.0.29. C’est cette version que nous utiliserons ici. Pour information j’ai testé la 7.4beta, mais il semble nécessaire d’attendre un peu avant de se jeter dessus ;).

N’ayant pas de système de type RedHat, j’ignore l’installation avec les RPMs et me tourne vers le TGZ.

Récupération de l’archive :

# wget ftp://ftp.sap.com/pub/sapdb/bin/linux/sapdb-server-linux-32bit-i386-7_3_0_29.tgz ...

Décompression de cette archive :

# tar zxvf sapdb-server-linux-32bit-i386-7_3_0_29.tgz sapdb-server-linux-32bit-i386-7_3_0_29/ sapdb-server-linux-32bit-i386-7_3_0_29/SAPDBDEP.TGZ sapdb-server-linux-32bit-i386-7_3_0_29/SDBINST sapdb-server-linux-32bit-i386-7_3_0_29/INSAPDB sapdb-server-linux-32bit-i386-7_3_0_29/SAPDBIND.TGZ

Se placer dans le répertoire contenant les exécutables d’installation :

# cd sapdb-server-linux-32bit-i386-7_3_0_29

La package contient 4 fichiers, dont un exécutable (SDBINST) qui est l’_installer_. Cet _installer_ fonctionne en mode console ce qui (à mon avis) est plutôt un avantage.

Lors de l’installation, il vous sera demandé quel utilisateur (et quel groupe) est propriétaire des programmes et données. Pour cela l’_installer_ vous propose de créer un utilisateur sapdb (groupe sapdb), mais cette opération a systématiquement échoué chez moi et je l’ai donc fait de manière traditionnelle avec un classique appel à adduser. Enfin il faut décider où nous voulons installer les fichiers (binaires, librairies, données…). Comme pour la création de l’utilisateur sapdb, des propositions sont faites lors de l’installation et vous pouvez parfaitement les adopter. De mon coté mon caractère contestataire m’a poussé à opter pour une centralisation dans /opt/sapdb (Pour la petite anecdote, l’installation de la version 7.4beta propose ce répertoire par défaut). En fait lors de l’installation il faut choisir trois emplacements :

  • un pour les programmes “indépendants” (/usr/sapdb/indep_prog) ;
  • un pour les données “indépendantes” (/usr/sapdb/indep_data) ;
  • un pour les éléments “dépendants” (/usr/sapdb/depend).

qui pour ma part sont devenus, respectivement :

  • /opt/sapdb/indep_prog ;
  • /opt/sapdb/indep_data ;
  • /opt/sapdb/depend.

Ceux-ci étant choisis, nous pouvons lancer SDBINST :

# ./SDBINST         Installation of SAP DB Server 7.3.0.29         ************************************** start installation Th, Jan 09, 2003 at 15:51:29 operating system: linux callers working directory: /root/sapDB/sapdb-server-linux-32bit-i386-7_3_0_29 start package for release independent database software ------------------------------------------------------- please enter independent program path [/usr/sapdb/indep_prog]: /opt/sapdb/indep_prog directory "/opt/sapdb/indep_prog" does not exist, create? (y/n) y please enter independent data path [/usr/sapdb/indep_data]: /opt/sapdb/indep_data directory "/opt/sapdb/indep_data" does not exist, create? (y/n) y WRN: history path "/opt/sapdb/indep_data/config/install" not found please enter group name for database programs [sapdb]: please enter owner name for database programs [sapdb]: collecting data finished... independent program path: /opt/sapdb/indep_prog independent data path: /opt/sapdb/indep_data owner: sapdb group: sapdb node:  skulie are these values correct? (y/n) y start dry extraction of "SAPDBIND.TGZ" ... check unpacked archive... check unpacked archive: ok start package for release dependent database software ----------------------------------------------------- new installation please enter dependent path [/usr/sapdb/depend]: /opt/sapdb/depend directory "/opt/sapdb/depend" does not exist, create? (y/n) y please enter group name for database programs [sapdb]: please enter owner name for database programs [sapdb]: collecting data finished... dependent path: /opt/sapdb/depend owner: sapdb group: sapdb node:  skulie are these values correct? (y/n) y start dry extraction of "SAPDBDEP.TGZ" ... check unpacked archive... check unpacked archive: ok installation of SAP DB Server finished successfully Th, Jan 09, 2003 at 16:12:00 #

Voilà, voilà. Notre SGBD est installé. A partir de maintenant il nous reste à démarrer le server et créer notre base. Toutes ses opérations se font sous le compte sapdb. La première chose à faire est donc de se logger sous ce compte et de s’assurer que nous avons accès aux programmes utilisés pour ces opérations. Pour cela il suffit simplement d’ajouter dans le fichier .profile de sapdb la ligne suivante :

export PATH=$PATH:/opt/sapdb/indep_prog/bin

Démarrage et arrêt du server

La commande de démarrage et d’arrêt du server est x_server. Cette commande est on ne peut plus simple :

$ x_server start   12798  NISERVER server started.   10007  XSERVER  started, 'X32|LINUX 7.3.0    Build 029-000-087-696'

Et notre server est lancé !

$ x_server stop   10005  XSERVER  stopped.

Et le server est arrêté.

x_server peut être utilisé avec différentes options et par habitude j’ai voulu le lancer avec l’option -h. Pas de chance je n’ai obtenu qu’un message d’erreur me disant que le fichier /opt/sapdb/indep_prog/env/vserver.use n’existe pas. En fait ce fichier se trouve dans /opt/sapdb/depend/env. Je vous laisse donc faire le lien et apprécier le résultat. Il faut pourtant que je vous avoue avoir aussi voulu essayer avec l’option –help ; J’obtiens alors un message me disant que cet option est invalide mais j’ai tout de même un résultat… Essayez !

Avant de continuer nous pouvons vérifier que notre serveur tourne bien. Pour cela vous avez différentes solutions possibles. La première, qui n’est pas sans intérêt, consiste à lancer la commande suivante sous le compte root :

# netstat -atnp

Chez moi la sortie est la suivante :

Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name tcp        0      0 0.0.0.0:7200            0.0.0.0:*               LISTEN      3780/vserver tcp        0      0 0.0.0.0:7269            0.0.0.0:*               LISTEN      3779/niserver tcp        0      0 0.0.0.0:7210            0.0.0.0:*               LISTEN      3780/vserver

Visiblement c’est bon. Mais comme deux précautions valent mieux qu’une, nous pouvons nous connecter directement au serveur en utilisant le “Database Manager Client” (dbmcli) fourni dans le package. Si vous lancez cette commande (en tant que user sapdb) sans aucun paramètre vous devriez obtenir un prompt :

$ dbmcli dbmcli>

Vous pouvez obtenir de l’aide sur les commandes disponibles avec un simple help. Pour le moment utiliser la commande “version” pour vérifier que votre server tourne bien :

dbmcli>version OK version,os,dbroot,logon,code,swap "7.3.0","UNIX","/opt/sapdb/depend",False,ASCII,2 --- dbmcli>

Création d’une base

Pour l’installation de bases, j’ai adopté la même méthode que pour l’installation et ai donc décidé de mettre les fichiers de données dans /opt/sapdb/DB. Dans ce répertoire j’ai choisi la solution qui consiste à avoir un répertoire par base. Pour notre exemple nous allons créer un base TST :

$ mkdir -p /opt/sapdb/DB/TST

C’est dans ce répertoire que seront placés les fichier de “devspace” (équivalent des tablespaces d’Oracle).

Il est possible de créer trois types de devspace :

  • DATA : Pour les données.
  • LOG : Pour les logs (identique aux “Archive Log” d’Oracle)
  • SYS : Pour le système.

De plus nous pouvons avoir plusieurs _devspace_ d’un même type. Par exemple si nous souhaitons créer deux _devspace_ de données on positionnera le paramètre MAXDATADEVSPACES à 2 avec la commande param_put de dbmcli. Dans notre cas nous allons créer deux _devspace_ :

  • un pour les données (DATA) : /opt/sapdb/DB/TST/dat_001 ;
  • un pour les logs (LOG) : /opt/sapdb/DB/TST/log_001.

la création d’un devspace se fait en utilisant la commande param_adddevspace de dbmcli. La syntaxe exacte est la suivante :

param_adddevspace <number> <mode> <master_name> <master_type> <size>    <number> : Numéro du devspace de mode <mode>    <mode> : Type de devspace (DATA, LOG ou SYS)    <master_name> : Nom du devspace    <master_type> : F pour File, R pour Raw device ou L pour Link    <size> : Taille (en pages) du devspace

Concernant la taille, elle est exprimée en “pages”. Il est donc intéressant de savoir ce que représente concrètement une “page”. Par défaut cela équivaut à 8192 octets. Cette valeur pouvant bien entendu être modifiée en utilisant le paramètre _PAGE_SIZE de la commande param_put de dbmcli.

Comme vous l’aurez compris la commande param_put permet de fixer un certain nombre de paramètres lors de la création d’une base. Je ne passerai pas en détail l’ensemble des paramètres possibles. Le tableau suivant vous présente les plus utilisés :

Paramètre Def.  
MAXARCHIVELOGS 4 Nombre max. de devspace d’archive log (1-32)
MAXDATADEVSPACES 10 Nombre max. de devspace de données (1-255)
MAXUSERTASKS 5 Nombre max. de sessions utilisateur
MAXDATAPAGES 10000 Nombre max. de pages pour l’ensemble des devspace
_PAGE_SIZE 8192 Taille (en Bytes) des pages
MAXLOCKS 1000 Nombre max. de locks sur les tables ou lignes
DATA_CACHE 300 Nombre de pages mémoire réservées pour le cache des données
DEFAULT_CODE ASCII ASCII, EBCDIC, INTERNAL ou UNICODE
DATE_TIME_FORMAT EUR EUR=DD.MM.YY, HH.MM.SS,
INTERNAL= YYYYMMDD, HHHHMMSS,
ISO,
JIS ou
USA
SESSION_TIMEOUT 600 Timeout d’une session SQL en seconde (30-100000)
LOG_MODE DUAL DUAL : Mise en place de deux devspace de log en miroir nécessitant un backup régulier afin d’éviter l’écrasement.
SINGLE : Un seul devspace nécessitant un backup régulier.
DEMO : Un seul devspace non protégé (écriture cyclique).

Si vous consultez la documentation de dbmcli vous verrez que l’option -i nous permet d’exécuter un “script” externe. Nous allons donc écrire un tel script pour le paramètrage de notre base :

File TST.sapdb :

1 param_rmfile  2 param_startsession  3 param_init  4 param_put MAXUSERTASKS 5  5 param_checkall  6 param_commitsession  7 param_adddevspace 1 LOG /opt/sapdb/DB/TST/log_001 F 1024  8 param_adddevspace 1 DATA /opt/sapdb/DB/TST/dat_001 F 2560  9 db_cold 10 util_connect 11 util_execute INIT CONFIG 12 util_activate dba,dba 13 util_release 14 load_systab -ud domain

Voyons en détail le contenu de ce fichier.

Ligne 2 : On ouvre une session de paramétrage qui charge (entre autre) le fichier de paramètre de la base (s’il existe) afin d’y faire des modifications ou des ajouts. En effet si l’instance (oui, en fait on devrait parler d’instance de base mais bon…) existe déjà, on peut parfaitement modifier ses paramètres. De même que si vous êtes perdu, vous pouvez parfaitement détruire complètement le fichier de paramétrage pour le recréer. C’est ce que l’on fait à la ligne 1 avec la commande param_rmfile.

Ligne 3 : Comme notre instance n’existe pas encore, il faut l’initialiser.

Ligne 4 : S’agissant d’une base de test, nous autorisons seulement 5 sessions utilisateur.

Ligne 5 : param_checkall permet de vérifier la validité des options choisis.

Ligne 6 : On ferme la session de paramètrage. C’est seulement à ce moment que les fichiers sont écrits sur le disque.

Ligne 7-8 : C’est à ce niveau que l’on définit la façon dont sont créées les devspaces. Le devspace d’archive log a une taille de 1024 pages soit 1024*8KB = 8192KB (8MB), celui de données a une taille de 2560 pages soit 2560*8KB = 20480KB (20MB).

Ligne 9 : La commande db_cold (ou db_start) permet de démarrer le noyau (Kernel) sans autoriser de connexion directe à la base.

Ligne 10 : Quand nous avons passé les commandes param_adddevspace nous n’avons fait que définir la configuration des devspaces, mais aucun fichier n’a encore été physiquement créé sur le disque. Pour cela il faut ouvrir une session “de service” (util_connect).

Ligne 11 : C’est à ce niveau que sont créés (physiquement) les fichiers de _devspace_ sur le disque.

Nous n’avons pas encore évoqué les utilisateurs pour la base. Par défaut il existe un utilisateur dbm. C’est le manager de la base. Il ne peut opérer qu’avant le démarrage de l’instance (ou pour arrêter une instance) de la base. Pour l’administration de la base à proprement parlé nous devons créer un utilisateur dba (Administrateur) qui peut travailler quand l’instance est lancée. L’utilisateur domain est un autre administrateur, propriétaire de certaines tables système, et il doit donc être reconnu au niveau de l’instance. La création de dbm est faite au moment de l’installation du SGBD.

Ligne 12 : Création du user dba (password dba).

Ligne 13 : On ferme la session de service.

Ligne 14 : On termine en chargeant les tables systèmes.

Nous pouvons enfin passer à la création de notre base. Pour cela nous allons utiliser dbmcli :

$ dbmcli -s -R /opt/sapdb/depend db_create TST dbm,dbm OK

C’est la commande db_create suivie du nom d’instance puis du login,password du dbm. -R permet de préciser quel SGBD vous utiliser. Ceci peut être utile dans le cas où plusieurs sont installés sur une même machine. L’option -s permet de spécifier que l’on travaille sur le noeud local. Si vous faites une installation distante, utilisez l’option -n suivie du nom d’hôte distant. Attention, dans ce cas, il faut aussi spécifier le login et le mot de passe du user système propriétaire de SAP DB :

dbmcli -n <host> db_create <inst_name> <dbm_user>,<dbm_passwd> <OS_user>,<OS_passwd>

Pour faire exécuter notre script TST.sapdb par dbmcli nous tapons la commande suivante :

$ dbmcli -d TST -u dbm,dbm -i TST.sapdb

Je ne détaille pas la sortie de cette commande. Vérifiez simplement que vous voyez apparaître le message “0,OK: everything works fine”.

La base est prête ! Vous pouvez le vérifier en tapant la commande

$ dbmcli -d TST -u dbm,dbm db_state OK State WARM

Si vous voulez vraiment être sure de vous, rien de mieux qu’un petit ps axf !

$ ps axf 20625 ?        S      0:00 /opt/sapdb/depend/pgm/kernel TST 20627 ?        S      0:00  \_ /opt/sapdb/depend/pgm/kernel TST 20628 ?        S      0:00      \_ /opt/sapdb/depend/pgm/kernel TST 20629 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20630 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20631 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20632 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20633 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20634 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20635 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20636 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20637 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20638 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20639 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20640 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20641 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20642 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST 20643 ?        S      0:00          \_ /opt/sapdb/depend/pgm/kernel TST

Si vous regardez dans le répertoire /opt/sapdb/DB/TST vous y retrouverez les deux fichiers de _devspace_ dat_001 et log_001. Ceux qui suivent seraient en droit de me demander ce qu’il en est du devspace SYS. La réponse se trouve dans le répertoire /opt/sapdb/indep_data/wrk/TST. Ce devspace étant obligatoire, il a été créé automatiquement dans le répertoire par défaut avec une taille de 144KB. Vous trouverez aussi dans /opt/sapdb/indep_data/config les fichiers de configuration de la base.

Avant d’aller plus loin je voudrais revenir sur les commandes db_cold et db_start. Ces deux commandes ont le même effet, celui de mettre la base en état COLD, à savoir que l’instance est démarrée mais qu’aucune requête ne peut être passée à la base. Pour mettre la base en état WARM il faut utiliser la commande db_warm ou db_restart. Enfin pour mettre la base offline vous avez le choix entre db_offline ou db_stop.

L’opération de destruction d’une base est très simple. Il suffit simplement d’utiliser la commande db_drop de dbmcli.

Création d’un nouvel utilisateur

La création d’un nouvel utilisateur se fait à l’aide de la commande sql CREATE USER :

CREATE USER <user_name> PASSWORD <password> [<user_mode>] [PERMLIMIT <unsigned_integer>] [TEMPLIMIT <unsigned_integer>] [TIMEOUT <unsigned_integer>] [COSTWARNING <unsigned_integer>] [COSTLIMIT <unsigned_integer>] [[NOT] EXCLUSIVE]

ou

CREATE USER <user_name> PASSWORD <password> LIKE <source_user>

ou

CREATE USER <user_name> PASSWORD <password> USERGROUP <usergroup_name>

Seul le user dba peut réaliser une telle opération. Ceci se fait en ouvrant une session SQL avec l’option -uSQL de dbmcli :

$ dbmcli -d TST -u dbm,dbm -uSQL dba,dba dbmcli on TST>sql_execute CREATE USER test PASSWORD test DBA NOT EXCLUSIVE OK ---

Nous pouvons tester tout de suite en nous connectant à la base avec le nouvel utilisateur :

dbmcli on TST>sql_connect test,test OK --- dbmcli on TST>quit --- $ _

Pour plus d’information sur la gestion des utilisateur et des droits, vous pouvez consulter la documentation en ligne à l’adresse http://www.sapdb.org/htmhelp/da/ed9036dfe4b903e10000009b38f889/frameset.htm

Création d’une table

Ayant un utilisateur test, nous pouvons créer un première table “person” avec CREATE TABLE :

CREATE TABLE <table_name> (<column_definition>[,<table_description_element>,...])   [IGNORE ROLLBACK] [<sample_definition>]

ou

CREATE TABLE <table_name> [(<table_description_element>,...)]   [IGNORE ROLLBACK] [<sample_definition>] AS <query_expression> [<duplicates_clause> ]

ou

CREATE TABLE <table_name> LIKE <table_name> [IGNORE ROLLBACK]

Ok ? Alors allons y :

$ dbmcli -d TST -u dbm,dbm dbmcli on TST>sql_connect test,test OK --- dbmcli on TST>sql_execute CREATE TABLE person ( id FIXED(4), fname VARCHAR(25), lname VARCHAR(25), account FIXED(7,2) ) OK --- dbmcli on TST>sql_execute INSERT INTO person ( id, fname, lname, account ) VALUES ( 1, 'Grégoire', 'Lejeune', 1000.57 ) OK --- dbmcli on TST>sql_execute SELECT * FROM person OK END 1;'Grégoire';'Lejeune';1000.57 --- dbmcli on TST>quit --- $ _

Comme pour la gestion des utilisateurs, voyez la documentation en ligne.

ODBC

Pour ceux qui connaissent ODBC, vous savez qu’il y a plusieurs possibilités pour l’utiliser avec perl : soit en compilant DBD::ODBC directement avec le driver, soit en utilisant le “driver manager”. Pour la suite j’ai adopté cette dernière solution car fournie comme telle dans la Debian. Pour cela il suffit simplement d’installer le package libdbd-odbc-perl et la magie d’apt-get fait que tout ce dont vous avez besoin sera également installé… Le driver manager (dans mon cas) est unixodbc, mais vous pouvez très bien adopter iODBC.

Juste histoire de vous remettre les idées en place, je vous rappelle qu’odbc utilise deux fichiers de configuration : /etc/odbcinst.ini dans lequel on trouve les informations sur les drivers et /etc/odbc.ini dans lequel sont définis les DSN (Data Source Name). Ces deux fichiers sont de type paramètre à section (comme les fichiers .ini sous Windows).

La première étape consiste donc à rajouter les informations sur le driver SAPDB dans /etc/odbcinst.ini. Pour cela nous devons connaître la librairie du driver à utiliser. Pour SAP DB il s’agit de libsqlod.so qui se trouve dans le répertoire /opt/sapdb/depend/lib. La librairie de setup est /usr/lib/odbc/libsapdbS.so fournie avec le package unixodbc. Nous rajoutons donc les lignes suivante dans odbcinst.ini :

[SAPDB] Description     = SAPDB Driver          = /opt/sapdb/depend/lib/libsqlod.so Setup           = /usr/lib/odbc/libsapdbS.so FileUsage       = 1

A la différence d’une config ODBC “normale”, SAP DB n’utilise pas les paramètres Database et Servername mais respectivement ServerNode et ServerDB. Nous rajoutons donc dans /etc/odbc.ini :

[TST] Description     = SAPDB Driver          = SAPDB ServerNode      = localhost ServerDB        = TST

Dernière chose à faire avant de se lancer dans le développement, créer un lien vers /etc/odbc.ini dans /usr/spool/sql/ini :

$ cd /usr/spool/sql/ini $ ln -s /etc/odbc.ini

Vous pouvez maintenant développer sereinement. Pour ma part, j’ai commencé par faire une petit programme (en fait je l’ai trouvé sur le net mais bon ;)) qui me donne la liste des drivers disponibles pour DBI et les DSN correspondant :

ODBC.pl :

#!/usr/bin/perl use strict; use DBI; $| = 1; map { print "Data sources for $_: " . join ( "\n", DBI->data_sources( $_ ) ) . "\n" }     grep( !/ADO|template/, DBI->available_drivers );

Voici la sortie obtenue :

$ perl ODBC.pl Data sources for ExampleP: dbi:ExampleP:dir=. Data sources for ODBC: DBI:ODBC:TST Data sources for Pg: Data sources for Proxy:

Nous voyons donc que le DSN pour accéder à notre base TST sous SAP DB est DBI:ODBC:TST. Testons !

testODBC.pl

#!/usr/bin/perl use strict; use DBI; my $dbh = DBI->connect('dbi:ODBC:TST', 'test', 'test'); ## On ajoute une ligne $dbh->do( "INSERT INTO person ( id, fname, lname, account ) VALUES ( 3, 'Stephane', 'Schildknecht', 777.66 )" ); ## Affichage de la table "person" $sth = $dbh->prepare( "select * from person" ); $sth->execute( ); while ( $sth->fetchrow_hashref ) {   my %h = %{$_};   foreach( keys %h ) {     print $h{$_}." ";   }   print "\n"; } $sth->finish( ); $dbh->disconnect( );

A bientôt…

Il reste encore beaucoup de choses à découvrir comme le backup/restauration ou la réplication. Sachez aussi que vous pouvez développer avec python, Java ou C/C++. Quoi qu’il en soit j’espère que cette présentation rapide de SAP DB vous donnera envie de poursuivre l’exploration.

Grégoire Lejeune
Stephane Schildknecht

• • •

3 commentaires »

  1. hello !
    j’aurais bien essayé … mais impossible de l’installer sur MacOsX :
    -bash: ./SDBINST: cannot execute binary file
    si non , saurait tu si il y a un connecteur ruby pour sapdb ?
    merci !

    Commentaire par kedare — Mercredi 7 mars 2007 @ 4:49
  2. Je ne vois pas bien comment résoudre ton problème vu qu’il n’existe visiblement pas de version de SapDB pour MacOSX…

    Pour ce qui est du connecteur Ruby, désolé encore une fois, mais je ne croie pas qu’il existe… Bonne piste pour celle ou celui qui souhaiterait s’essayer à faire un binding ;)

    Commentaire par greg — Vendredi 9 mars 2007 @ 18:24
  3. Suis-je bête ! Pour le connecteur Ruby, il y a ODBC !

    Commentaire par greg — Vendredi 9 mars 2007 @ 18:25

RSS des commentairesTrackBack URI

Laisser un commentaire

You must be logged in to post a comment.

Powered by: WordPress • Template adapted from the Simple Green' Wench theme - RSS