Discussion :

[BigNoze]

Bonjour à tous (Ô Grands Manitous Delphinesques )
Etant quelqu'un de tétu et chevronné je persiste dans mes fichiers typés pour gerer mes enregistrements

Par contre un tout piti probleme : comment modifier un enregistrement ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
Procedure MajClient;
var
  Client : TClient;
begin
  AssignFile(fic_client, 'Fic_Client.dat');
  if fileexists ('fic_client.dat') then
  begin
    reset (fic_client);
    seek(fic_client,Client_Index);
  //  write(fic_Client);
  end
  else
  begin
  rewrite (fic_client);
  end;
  Client.Code := F_EcrPr.E_Cli_1.Text;
  Client.Nom := F_EcrPr.E_Cli_2.text;
  Client.Adresse1 := F_EcrPr.E_Cli_3.text;
  Client.adresse2 := F_EcrPr.E_Cli_4.text;
  Client.CP := F_EcrPr.E_Cli_5.text;
  Client.Ville := F_EcrPr.E_Cli_51.text;
  Client.Tel1 := F_EcrPr.E_Cli_6.text;
  Client.tel2 := F_EcrPr.E_Cli_7.text;
  Client.fax := F_EcrPr.E_Cli_52.text;
  Client.portable := F_EcrPr.E_Cli_53.Text;
  Client.mail := F_EcrPr.E_Cli_8.Text;
  Client.soc := F_EcrPr.E_Cli_9.Text;
  Client.Compta := F_EcrPr.E_Cli_54.Text;
  Client.APE := F_EcrPr.E_Cli_10.Text;
  Client.TVA := F_EcrPr.E_Cli_55.Text;
  Client.Activite := F_EcrPr.E_Cli_11.Text;
  Client.Remarque1 := F_EcrPr.E_Cli_12.Text;
  Client.Remarque2 := F_EcrPr.E_Cli_13.Text;
  Client.Remarque3 := F_EcrPr.E_Cli_14.Text;
  Client.Reglement := F_EcrPr.E_Cli_15.Text;
  Client.RIB := F_EcrPr.E_Cli_16.Text;
  Client.Banque := F_EcrPr.E_Cli_17.Text;
  Write(fic_Client, Client);
  CloseFile(fic_Client);
end;

Et là l'enregistrement s'insere à la bonne position mais décale la suite donc je me retrouve avec en position n mon enregistrement modifié et en n+1 l'enregistrement original - j'aurai aimé que l'enregistrement modifié ecrase l'original (je sais je sais c'est le principe de la mise à jour )..

Merci à vous tous pour vos réponses et au temps que vous avez deja consacré à m'aider.... (je vous citerai comme co-auteurs si mon projet se finalise un jour ... )

[TicTacToe]

Bon je veux pas être sarcastique, mais là t'es buté!

Mais là, bin tu tombes typiquement sur un problèmes largement résolu par une base (comme tu le soulignes...)

Note toi sur un papier le temps que tu perds à essayer de résoudre un tel problème, alors que c'est déjà fait en BD.
Et ce sera pas le dernier problème.
Et quand tout marchera (car j'espère que ton prog aboutira), avec la masse de données que tu comptes mettre dedans, il sera inutilisable car trop lent...

Et si tu ajoutes une informations, que tu changes un id, que tu suprrimes une infos... ?

Tes recherches, tu va les faire séquentiellement à chaque fois ? vaut mieux pas s'appeler 'Zorglub'

Enfin, sinon j'ai pas la réponse à ta question.

mais je voulais insister encore une fois sur le fait que tu es en train d'utiliser un tournevis pour enfoncer un clou !...

Bon courage !

[BigNoze]

Bon je veux pas être sarcastique, mais là t'es buté!

Bon courage !

Je sais Je sais mais petite explication succinte sans forcement raconter ma vie...
En fait je commercialise un programme de gestion depuis 6 ans (pas fait par moi ) qui fonctionne sur ce type de "base de données" -
y compris formation parametrage et SAV...
De grands editeurs (Sage pour ne pas le nommer) trouve le concept tres abouti non pas la gestion co (qui est limite) mais ce systeme de stockage de données car il est clair que tu fais une copie du dossier sur un portable ou une clef usb et ton appli est fonctionnelle,
chose que tu n'as pas avec une base de donnée (tu prends une base access pour avoir à peine un peu de communication avec d'autres choses il te faut le moteur jet (ou si je me trompe c'est Que mon BTS info de gestion m'a servi à rien )
Tu veux modifier la taille des champs à l'install avec ce systeme c'est tout simple

Si tu veux un minimum de performance c'est clair il faut passer en sql : donc moteur sql sur les postes nomades, sur le serveur ...
Et question sauvegarde : si tu veut etre fiable il te faut un logiciel de sauvegarde base ouverte en sql donc encore une fois tu sors l'artillerie lourde...

Mon concept etant clair je veux m'adresser au magasin de fruits et legumes (c'est un exemple pour de donner la taille de la clientele visée)...
avec de un à 5 postes en reseau
une sauvegarde en .bat ... un truc simple en fait pour l'utilisateur lambda
Et si un jour tu as un appel te disant que l'appli ne fonctionne plus (je ne me le souhaite pas mais cela arrive ) je ne veux pas au telephone verifier si les liens odbc sont correct, si le serveur sql est operationnel
je veux etre autonome dans le fonctionnement

Si tu as un probleme reseau un jour avec des simples copies sur les postes tu peux demarrer en mode hors connexion puis fonctionner comme ca ...
sans te soucier de savoir si le poste a ete reformaté par son cousin qui est ingenieur en informatique mais qui a oublié de reinstaller les pilotes odbc... (c'est du vecu ca...) donc toi tu es en deplacement et tu as un magasin totalment planté a l'autre bout de la france..

enfin tout cela quoi mais me trompes je peut etre?

En tout cas mon experience personnelle m'a mis sur cette voie (de garage peut etre)...
Mais c'est clair que si j'arrive à mener a bien mon projet j'ai deja une clientèle de preneurs...
Et cela me permettra peut etre de pouvoir faire travailler un developpeur chevronné comme toi pour faire le portage sous BDD et me prouver que j'avais tord...

Voili voila toute l'histoire....
Merci qd meme de tes reponses et conseils

[denokan]

ok tu insistes, alors j'insiste moi aussi

avec mybase tu devrai pouvoir enregistrer tes données comme tu le souhaite, et pour le déploiement il te suffit d'inclure la dll midas.dll, ou alors tu peut même l'inclure dans ton exe, et bénéficier des facilités du fichier typé, mais aussi de celle de la base de données.
http://jmcarayon.developpez.com/mybase/

je viens de faire un test et effectivement même sans la dll ça fonctionne très bien

bon courage pour trouver un contre-exemple

[TicTacToe]

Il est certains qu'une base de ce type à des avantages.
à contrebalancer avec les inconvénients (comme toujours )

Mais les arguments que tu avances ne sont pas tout à fait corrects.
Je me permets de donner mon point de vue.

De grands editeurs (Sage pour ne pas le nommer) trouve le concept tres abouti non pas la gestion co (qui est limite) mais ce systeme de stockage de données car il est clair que tu fais une copie du dossier sur un portable ou une clef usb et ton appli est fonctionnelle,
chose que tu n'as pas avec une base de donnée (tu prends une base access pour avoir à peine un peu de communication avec d'autres choses il te faut le moteur jet (ou si je me trompe c'est Que mon BTS info de gestion m'a servi à rien )

C'est vrai que le stockage est simple.
Mais une BD n'est pas forcément un client/serveur dans son intégralité (lourd à installer en général effectivement).
Comme j'utilise Paradox, je parle de cette BD que je connais. Elle est légère et simple. Un serveur de fichier suffit.
--> Les données + le prog sur une clef USB peut parfaitement fonctionner. Il y a un prog client BD à installer, léger et simple qui peut d'ailleurs être facilement intégrer à l'install de ton propre logiciel (et encore, MFDev à une solution très sympa pour ne même pas installer le moteur de données (BDE) donc cela est transparent pour le user).
Donc argument non valable pour certaines BD.

Tu veux modifier la taille des champs à l'install avec ce systeme c'est tout simple

C'est à dire ? décider que la désignation doit faire 30 au lieu de 40 car ? dans ce cas tu es aussi embeté qu'un autre prog. Car soit tu dois modifier tes contraintes dans le prog (donc recompiler ton prog...), soit changer un fichier de description (et là, c'est intégré dans un descriptif BD de la même manière). Mais je concois que cela peut être plus simple dans certains cas.
Allez, argument semi-valide on va dire

Si tu veux un minimum de performance c'est clair il faut passer en sql : donc moteur sql sur les postes nomades, sur le serveur ...

Totalement faux. La base Paradox n'a pas besoin d'un programme serveur. La base est utilisée uniquement en serveur de fichiers. Quant au SQL il est absolument pas indispensable, même au contraire si tu veux atteindre de bonne performances. Quant à parler de performance par rapport à des fichier texte... ce sera surement plus rapide avec un très faible volume, la limite sera franchie très rapidement quand le volume augmentera amha
Je parle toujours de Paradox car je la connais, mais d'autres bases plus récentes existes de la même manière.

Et question sauvegarde : si tu veut etre fiable il te faut un logiciel de sauvegarde base ouverte en sql donc encore une fois tu sors l'artillerie lourde...

La sauvegarder est des plus simple à réaliser, puisqu'il il suffit de sauver le dossier ou sont tes fichiers BD.
Par contre effectivement, il est impératif de fermer les bases pour les sauver. On ne peut pas sauver la base pendant qu'elle est utilisée.
C'est une contrainte... Mais même en fichier texte, si tu sauves ta base pendant l'utilisation, tu risques d'avoir des surprises et des dé-synchronisations sur des liaisons...

Mon concept etant clair je veux m'adresser au magasin de fruits et legumes (c'est un exemple pour de donner la taille de la clientele visée)...
avec de un à 5 postes en reseau

Comment gère tu tes verrouillages réseau avec des fichiers texte ? Le style de base que j'ai cité est l'idéal pour de petits réseau.

une sauvegarde en .bat ... un truc simple en fait pour l'utilisateur lambda

Oui, le même .bat avec la base stockée dans un dossier BD...

Et si un jour tu as un appel te disant que l'appli ne fonctionne plus (je ne me le souhaite pas mais cela arrive ) je ne veux pas au telephone verifier si les liens odbc sont correct, si le serveur sql est operationnel
je veux etre autonome dans le fonctionnement

Pas de serveur SQL dans notre cas...
L'appli ne fonctionne plus... cela peut venir de X raisons. Mais avec des fichiers texte comme avec une base, cela peut être compliqué et nécessiter ton intervention. Il te faudra redev. des outils pour réparer une base éventuellement endommagée... qui existe déjà en BD. Si tu dis au User 'recopier juste le fichier clients.txt' dans ce dossier, tu risques effectivement de ne pas avoir d'erreur de contrôle au niveau BD (géré par toi) mais d'être dans une situation incohérente au niveau des liens de tes fichiers.

Si tu as un probleme reseau un jour avec des simples copies sur les postes tu peux demarrer en mode hors connexion puis fonctionner comme ca ...
sans te soucier de savoir si le poste a ete reformaté par son cousin qui est ingenieur en informatique mais qui a oublié de reinstaller les pilotes odbc... (c'est du vecu ca...) donc toi tu es en deplacement et tu as un magasin totalment planté a l'autre bout de la france..

Que ce soit des fichiers texte ou de la BD Paradox, le problème sera le même, il faudra recopier prog+datas autre part, éventuellement indiquer au prog ou sont les Datas. donc kif-kif.

En tout cas mon experience personnelle m'a mis sur cette voie (de garage peut etre)...
Mais c'est clair que si j'arrive à mener a bien mon projet j'ai deja une clientèle de preneurs...
Et cela me permettra peut etre de pouvoir faire travailler un developpeur chevronné comme toi pour faire le portage sous BDD et me prouver que j'avais tord

Je ne prétends pas être spécialement chevronné, bien que ce soit sympa , mais je voulais simplement te faire partager mon expèrience et te signaler que bon nombre des tes arguments sont erronés par manque de connaissance sur les BD je pense.

L'avantage que tu vois je pense, c'est qu'en cas d'anomalie, il n'y aura pas de moteur de données qui bloquera à cause d'un problème d'incohérence. Mais le problème sera là !
Alors que vaut-il mieux ?
- être bloqué par le moteur BD qui vérifie la cohérence, et réparer de suite ?
ou
- ne pas être bloqué par une incohérence non décelée, croire que tout est OK, travailer 2 semaines dessus et s'apercevoir au bout de 2 semaines de saisie que tout est à ressaisir à cause d'une anomalie de départ ?

Enfin, sinon, développer un moteur de BD (car c'est de cela qu'il s'agit), doit être super interessant en expèrience, et tout n'est pas à faire puisque c'est dédié à ton utilisation, donc c'est possible.
Mais c'est pas le meilleur rendement !

Bon courage en tout cas

PS: je me suis laché là

[Graffito]

Bonjour,

Il me semble quil'y a un problème lié au rewrite lorsque le fichier n'existe pas : il faudrait écrire "Client_index-1" records.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
  ...
  else  begin
         rewrite (fic_client);
         for i:=0 to Client_Index-1 do write(fic_Client);
         end;
....

Sans préjuger du bien fondé du choix de fichiers records, je te conseillerais de définir des procédures de gestions de fichiers records communes à l'ensemble des tables avec un objet Table qui proposerait des methodes comme :
- Open(file_name,size_of_record,force_create_if_non_existent)
- Read/write(Table_Index,Record_Pointer)
- ...

[BigNoze]

Est on obligé de marquer le problème avant de se suicider ?
C'est decidé je bascule tout le toutim sous MyBase
je vais donc me mettre à potasser cet outil...
je pense que je ne vais pas manquer de vous enquiquiner avec d'autres questions stupides
Par contre vous avez interet à me repondre
Un site sur Mybase la comme ca????????

et hop je marque comme résolu mais c'est vraiment pour vous faire plaisir!!!!

Merci à tous mais ce n'est qu'un debut
-------> Alex <--------
PS Si ma femme divorce car je passe des nuits a tout refaire je vous en tiendré comme principaux responsables

[TicTacToe]

lol

MyBase je connaissais pas, et semble être à mis chemin (plutot coté BD qd même) des fichiers textes.

le lien de Developpez cité par Denokan donne une bonne impression.

Mais ou alors j'ai mal compris, mais la base est chargée totalement en mémoire et tous les traitements BD sont fait en mémoire ??? donc dans ce cas là c'est une base exclusivement mono-poste ?

Sinon, il y a Paradox (évidemment je cite) mais base un peu vieille maintenant mais toujours performante et simple pour de petit réseaux.
Sinon DBExpress, son remplacant... a creuser, je connais pas bien.

Choisi la bonne base, adapté à ton besoin.
Vérifie que MyBase peut être utilisée en réseau (vu que tu veux l'installer pour 5 postes par exemple).

Enfin,... je pense que tu as raison de t'orienter vers une BD. Même si ca fait 3 heures que je dis que le fichier texte c'est le top... non je déconne

[denokan]

mybase est un remplacant à BDE en monoposte, mais je ne sais pas ce qu'il peut donner avec un gros volume d'infos et/ou une utilisation réseau, mais je garde de très mauvais souvenir de Paradox/BDE en réseau local (sous win98)... pour mes projets actuels, j'envisage plutot une base sur FireBird, qui semble adapté à une utilisation sur un réseau, sans trop de dépenses à l'achat
par contre le prob auquel tu viens d'être confronté devrai te convaincre de concevoir ton logiciel d'une autre facon : ton programme est un ensemble de moteurs qui inter-agissent : il y a le moteur d'accès au fichier, le moteur de traitement des données, le moteur d'affichage, le moteur d'impression... avec des proc du style EnregistreClient(TClient) qui recoit en paramètre une classe et qui se charge de l'enregistrer correctement... c'est un peu plus lourd à coder mais l'avantage c'est que tes moteurs échangent entre eux des classes (ou des records) et que le seul à "savoir" comment enregistrer sur le disque est le moteur d'accès aux fichiers... ainsi, quand tu décides de changer de format de fichier (que ce soit pour des record, mybase ou firebird) tu ne devra recoder que la partie d'accès aux fichiers, qui sera sûrement dans une seule unité pascal... donc il est bien plus facile de mettre à jour et faire évoluer ton soft +

[BigNoze]

devrai te convaincre de concevoir ton logiciel d'une autre facon : ton programme est un ensemble de moteurs qui inter-agissent : il y a le moteur d'accès au fichier, le moteur de traitement des données, le moteur d'affichage, le moteur d'impression... avec des proc du style EnregistreClient(TClient) qui recoit en paramètre une classe et qui se charge de l'enregistrer correctement... c'est un peu plus lourd à coder mais l'avantage c'est que tes moteurs échangent entre eux des classes (ou des records) et que le seul à "savoir" comment enregistrer sur le disque est le moteur d'accès aux fichiers... ainsi, quand tu décides de changer de format de fichier (que ce soit pour des record, mybase ou firebird) tu ne devra recoder que la partie d'accès aux fichiers, qui sera sûrement dans une seule unité pascal...

En effet MyBase à l'air exclusivement monoposte (dixit borland)
Concernant les procedures c'est vrai qu'en faisant comme tu l'enonces ca devrait etre bien mieux je vais m'y mettre
en faite je ne conserve que les forms (merci )

mais concernant la base je ne sais que choisir
sachant que je souhaite reelement l'attaquer en direct depuis l'appli, et meme la creer depuis l'appli...


Merci qd meme..

[TicTacToe]

je te conseillerais Paradox.
Mais mon avis est (très) déformé car c'est un base que je connais très bien.

Mais il faut savoir que le BDE (Borland Database Engine) qui est le moteur sur chaque client n'est plus maintenu et ne subit plus de mise à jour...
Par contre elle est simple d'utilisation avec les composants Delphi, c'est une base connue, donc bcp d'outils sont à disposition.

Pour ma part, pour te donner un apercu, j'ai 30 clients qui travaillent sur plusieurs applis interconnectées depuis quelques années tous les jours. Actuellement une des bases atteinds 1.5Go (defragmentée) dont table jusqu'à 500Mo et 1 300 000 enregs. L'appli est trés rapide ainsi que les temps de réponses (sinon me serait déjà fait taper dessus ). Pratiquement pas de SQL dedans, on peut s'en passer dans 99% des cas, ce qui permet d'ailleurs un meilleur contrôle dans l'utilisation des index. La base est pratiquement jamais cassée (1 fois tous les 6 mois).
Voila, je pense que je suis pas loin des limites annoncées, mais force est de constater que ca ne rame absolument pas.

D'ailleurs qd on voit les comparatifs de vitesse sur Developpez, MyBase est un peu plus rapide dans les accès... mais les données sont en mémoire ! donc c'est qd même fort que paradox puissent être comparé avec ceci (dont les accès sont sur le disque.) ou alors je dis une connerie ?!

Voila, après je suis persuadé que les nouvelles bases comme DBExpress fonctionnent bien aussi mais je pourrais pas témoigner.

Il faut prendre les témoignages des autres, de documents et retirer toutes les infos objectivement.

Bon courage !

[BigNoze]

et elle est gratuite????

[TicTacToe]

Paradox ? oui, aucune licence a acquerir si ce n'est celle de Delphi qui possède Paradox, au moins version pro, pour le développeur.

Sinon, après, l'appli utilisant paradox est libre (enfin t'appartient et tu en fais ce que bon te semble)

mais renseigne toi qd même sur les autres bases, ne regrette pas d'avoir choisi celle ci ensuite. c'est le moment, avant de creer ton appli. après il est souvent trop tard...

[denokan]

(erreur)

[denokan]

en fait le soucis avec paradox, c'est qu'il faut le déployer avec le BDE, alors qu'avec mybase tout est inclus dans l'exe... j'ai fait un test tout à l'heure sur une base mybase avec 100000 records et ça fonctionne correctement... à mon avis tu devrai faire un test sur un ensemble de données concret avec chacun, comparer les performances et choisir le meilleur. ca ne devrais pas être laborieux, car l'utilisation de mybase est très similaire à celle de BDE. dans tous les cas je garde moi-même un très mauvais souvenir de paradox en réseau.

[TicTacToe]

Denokan
Le probleme c'est que MyBase et Paradox ne sont pas comparables.
Certe, L'interface mise à disposition du dev. est la même (BDE), mais dans le fonctionnement, c'est totalement différent.

MyBase est
- mono utilisateur
- chargée en mémoire (Le loadFromFile) ou alors j'ai pas bien compris.
C'est pour cela d'ailleurs, sur le lien developpez que tu donnes, que l'ouverture de la base est infiniment plus rapide que Paradox (chargement des données en mémoire), et que les accès style SetRange sont un peu plus rapide
--> On est en train de comparer une base qui fait des accès mémoire à une base qui fait des accès disque ! Je trouve justement que Paradox s'en sort pas trop mal pour la comparaison non ?

De plus, en terme de volume, cela n'a rien à voir je pense non plus.

Donc, MyBase est vraiment dédiée pour de très petit volume (style ne jamais depasser 100/200Mo au total sur la base) et surtout... mono utilisateur. Mais une fois chargée, les performances sont inégalables.

Pour le dév. de BigNoze, je pense pas que ce soit adaptée.

Quant à tes mauvais souvenir on ne peut rien y faire, peut être n'avait tu pas une assez bonne connaissance de l'utilisation de Paradox à ce moment là.
Les défauts de Paradox sont:
- limitée en nombre de users simultanée (au delà de 50 on prends des risque de chute de perf)
- limité dans les tailles (au dela de 1Go par table, pareil, ca risque de ramer grave)
- base non client/serveur ( en cas de coupure inopinée d'un client, la base peut se retrouver cassée).
- plus de mise à jour
- peu évolutive vers l'exterieur. (Internet...)
--> Donc c'est clair c'est pas une base pour un parc de 500 personnes.

Les qualités par contre:
- très simple d'utilisation
- très performante, en lecture comme en écriture.
- on peut s'affranchir du SQL, ce langage est quand même préhistorique même si très utilisé, tout en étant plus performant dans les requêtes.
- la base ne grossit pas de manière dramatique
- parfaitement intégrée à Delphi

C'est donc une question de choix, pour une appli sur un parc de taille raisonnable pour une appli Locale, je pense que c'est l'idéal.

mais ne connaissant pas DBExpress par exemple, ou Ado qui sont plus modernes, il vaut peut être mieux se tourner vers ces bases maintenant.

[denokan]

l'avantage que je citais pour mybase, c'est qu'il n'utilise pas le BDE (même s'il utilise une interface relativement similaire), donc pas de moteur externe ; par contre j'imagine bien que pour une utilisation réseau ou sur de très gros volume les résultats ne seront pas là .
pour reparler de mon expèrience sur Paradox, j'avais une appli pour sortir des factures, qui utilisait une table fournisseurs (150 records), une table clients (250 records), une table articles (100 000 records) et je créais une une table pour chaque facture / devis (c'était sans doute une erreur énorme d'ailleurs ) ; le tout fonctionnant sous windows 98, avec l'application installée sur un seul poste qui la partagait via le réseau local sur 1 autre poste. et tous les jours, j'avais au moins une table qui merdait. si je devais recommencer avec la même base aujourd'hui, je changerai sûrement 2 ou 3 points d'ailleurs , mais maintenant que j'ai jeté un oeil sur FireBird, c'est tellement simple à utiliser que je trouve dommage de s'en priver quand on a le luxe de pouvoir imposer le système de fichier à l'utilisateur
dans tous les cas si BigNoze suit mon conseil de coder les accès aux fichiers dans un moteur à part du reste du traitement des données, la migration vers un autre système de fichiers devrait se faire en douceur

[okparanoid]

Et les composants ado avec une base access ? Ca necessite pas de config special sur le client ou je me trompe ?

[e-ric]

Salut

J'apporte un petit complément, le BDE est sans avenir et n'est pas porté en Dot Net.

Les clientDataSet logent toutes leurs données en mémoire, alors attention pour les volumes de données importants.

Pourquoi ne pas opter pour une base de données SQL relativement légère comme FireBird ? elle peut être installée en mode Embedded (client+serveur ensembles) si je me souviens bien. L'avantage est la stabilité et le confort, Firebird est gratuit mais les composants adaptés ne le sont pas forcément (faire des recherches). Autre avantage, avec FireBird peu de problème d'échelle, il est possible de travailler sur un volume de données important et pour un nombre de poste assez élevé aussi, ce qui peut être un plus commercial si tu vise des clients plus importants dans le futur. De nombreux éditeurs ont déjà choisis ce SGBD.

En ce qui concerne le paramètrage des données, rien ne t'empêche de coder un script paramétré pour la création de ta base.

cdlt

e-ric (nostalgique des SGBD SQL)