Discussion :

[SergioMaster]

jusque là j'utilisai pour des 'tables de travail locales' (sur le poste de travail) des tables PARADOX via BDE .

Maintenant je voudrai abandonner BDE , quel serait alors le meilleur choix :
(à exclure table en mémoire : la table de travail peut être importante
table CSV : j'ai au moins un champ mémo qui peut contenir n'importe quoi)

je me tâte entre garder PARADOX mais avec quelle liaison (ADO ?)
ACCESS
ou autres solutions ?

précisons que ces tables peuvent/doivent être indexées

[aityahia]

je vous dirais ACCESS et ADO mais sa a toujours ces petites anicroches car elle nécessite souvent des opération de maintenance, comme vous est en local pas de soucis vous pouvez effectuer la maintenance de votre base quand vous voulez

[SergioMaster]

ACCESS & ADO est ce que je suis en train de tester

ces petites anicroches

c'est quoi ces anicroches ? je n'aurai aucun moyen de maintenir la base sur chaque poste

[Rayek]

En fait tout dépendra de ce que tu veux faire et du volume de données que ton application gèrera.

(Je ne met que les bases de données connues)

Petites applications (- de 200k enregistrements)

• Locales : Paradox, Access, MySQL, FireBird, etc ...
• Reseaux : Les même que plus haut sauf qu'il vaut mieux eviter Paradox qui n'est pas vraiment recommandé pour le réseau (même si c'est possible)

Applications Moyennes (200k à 1M Enregistrements)

• Locales/Reseaux : Access, MySQL, FireBird, etc ...

Grosses Applications (+ 1M Enregistrements)

• Locales : A oublier
• Reseaux : SQL Serveur, Oracle, Db2, etc ...

(Les chiffres sont à titre d'exemple et peuvent être plus ou moins gros selon les bases de données, c'est surtout une moyenne pour l'exemple)

Une chose est sur, c'est que dès qu'une application devient Moyenne ou grosse, il faut oublier le traitement des données avec des composants de type TxxxTable et s'orienter vers les requetes (pour ma part c'est indispensable et obligatoire dès qu'il y a au moins 50k de données à traiter).

[ALWEBER]

Dès que tu accèdes à une table paradox tu utilises le BDE que ce soit au travers ODBC ou autre.
Gràce à quelques particularités c'est à ce jour le plus puissant (mais pas forcément le plus facile) moyen d'accès aux données en local. Si tu as besoin de quelques infos techniques je suis à ta disposition.

[Rayek]

Dès que tu accèdes à une table paradox tu utilises le BDE que ce soit au travers ODBC ou autre.
Gràce à quelques particularités c'est à ce jour le plus puissant (mais pas forcément le plus facile) moyen d'accès aux données en local. Si tu as besoin de quelques infos techniques je suis à ta disposition.

De nos jours, le BDE est plus contraigniant qu'autres choses (Obsolète, plus mis à jour, a du mal à fonctionner sur les nouveaux OS, Contrainte d'installation lors du deploiement, etc ...)

Maintenant, il vaut mieux se trouner vers les composants ADO, DbExpress ou Spécifique à une base de données que d'utiliser le BDE.

[SergioMaster]

De nos jours, le BDE est plus contraignant qu'autre chose (Obsolète, plus mis à jour, a du mal à fonctionner sur les nouveaux OS, Contrainte d'installation lors du deploiement, etc ...)

je voulais effectivement éviter BDE à cause de ça , j'aimais bien pourtant

donc si j'ai bien compris bien PARADOX implique d'installer BDE même si j'utilise une liaison ADO ? ce qui implique ACCESS (nota : un fichier de travail n'arrivera jamais a + de 200k enregistrements)

[Rayek]

je voulais effectivement éviter BDE à cause de ça , j'aimais bien pourtant

donc si j'ai bien compris bien PARADOX implique d'installer BDE même si j'utilise une liaison ADO ? ce qui implique ACCESS (nota : un fichier de travail n'arrivera jamais a + de 200k enregistrements)

Non, pas besoin du BDE pour te connecter à Paradox.
Ado + l'utilisation du Drivers ODBC Paradox (fournit en standard avec Windows) suffit largement.
Mais bon, avec Paradox, le SQL est fortement limité, il serait peut être préférable de migrer vers une autre base de données.

[aityahia]

Anicroche je dirais la contrainte de compacter périodiquement votre base sinon vous allez vous retrouvez avec des perturbations dans le tris des enregistrement s et la taille de la bases qui ne régresse pas lors des suppressions d'enregistrements ( suppression logique).

quand vous travailler en local le compactage ne pose aucun problème, vous pouvez le faire a chaque fois que vous quittez votre application mais en réseau ce qui n'est pas votre cas c'est un peut ambigu parce que pour le faire tous les autres utilisateurs doivent se déconnecter de la base pour faire l'opération.

[ALWEBER]

Je ne rentrerai pas totalement dans la polémique. Je travaille actuellement entre autres pour un client qui utilise Paradox. Plusieurs centaines de personnes sont connectées aux tables Paradox en réseau. Certaines de ces tables font plusieurs centaines de Mega-octets et dépassent le million d'enregistrements.
Que la politique commerciale de certains constructeurs comme Microsoft notamment par des prises de participation chez Microsoft et Corel ait visé à éloigner ce produit n'enlève rien à la qualité de ce format de base de données et de ses outils d'exploitations.
Je le répète si tu souhaites des infos pour mettre en oeuvre une solution Paradox je peux t'aider.
Je mets actuellement en service chez trois client une solution Intra/Extranet développée en .NET développée avec Delphi 2006 et des bases Paradox. Je fais une utilisation intensive de la fusion XML/XSL. Au point de vue qualité et temps de réponse c'est génial.

[SergioMaster]

Je le répète si tu souhaites des infos pour mettre en oeuvre une solution Paradox je peux t'aider.

je te remercie pour l'offre , mais si je suis novice avec ADO ce n'est pas le cas en ce qui concerne PARADOX via BDE que j'utilise sans souci pour ces tables de travail (définition : table temporaire sur le poste de l'utilisateur, utilisée uniquement par lui , dans un souci d'optimisation de certains traitements) , donc tu vois, rien à voir avec réseau et/ou internet .

Le sujet de mon post était surtout de savoir si :

1. PARADOX pouvait être utilisé sans BDE
2. il y a des alternatives à PARADOX (bien sur je savais qu'il y avait ACCESS) sans avoir d'installation (BDE,serveur BDD etc... a faire sur les postes 'clients'
3. les critères de choix

mes tests avec ACCESS & ADO m'ont révélé des choses étranges (anicroches d'aityahia ), qui me font regretter le BDE où un emptytable suffisait à mon bonheur .


effacement d'une table puis création

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
ADOConnection1.Connected:=True;
ADOCommand1.CommandText:='DROP TABLE ETIQUETTES';
ADOCommand1.Execute;
// si omi les enregistrements inserrés  restent !!!!
// c'est le seul moyen que j'ai trouvé pour faire un Commit
ADOConnection1.Connected:=False;  
ADOConnection1.Connected:=True;
SQLText:=TStringlist.Create;
try
 SQLText.Add('CREATE TABLE ETIQUETTES');
 SQLText.Add('(NUMERO SMALLINT NOT NULL,');
 SQLText.Add(' ARTICLE CHAR(17),');
 SQLText.Add(' POINTURE CHAR(3),');
 SQLText.Add(' DESCRIPTION CHAR(40),');
 SQLText.Add(' NOMIMAGE CHAR(80),');
 SQLText.Add(' CODEBARRE CHAR(25),');
 SQLText.Add(' DESSUS CHAR(25),');
 SQLText.Add(' TEXTILE TEXT');
 SQLText.Add(')');
 
ADOCommand1.CommandText:=SQLText.Text;
ADOCommand1.Execute;

[Rayek]

J'ai rajouté les transactions dans ton code (vu que tu parle d'un commit quelques part )

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
 
ADOConnection1.Connected:=True;
AdoConnection1.BeginTrans; // Début de la transaction
try
  ADOCommand1.CommandText:='DROP TABLE ETIQUETTES';
  ADOCommand1.Execute;
 
   SQLText:=TStringlist.Create;
   SQLText.Add('CREATE TABLE ETIQUETTES');
   SQLText.Add('(NUMERO SMALLINT NOT NULL,');
   SQLText.Add(' ARTICLE CHAR(17),');
   SQLText.Add(' POINTURE CHAR(3),');
   SQLText.Add(' DESCRIPTION CHAR(40),');
   SQLText.Add(' NOMIMAGE CHAR(80),');
   SQLText.Add(' CODEBARRE CHAR(25),');
   SQLText.Add(' DESSUS CHAR(25),');
   SQLText.Add(' TEXTILE TEXT');
   SQLText.Add(')');
  ADOCommand1.CommandText:=SQLText.Text;
  ADOCommand1.Execute;
  AdoConnection1.CommitTrans; // On valide la transaction
Except on E:Exception do
  begin
    AdoConnection1.RollBackTrans; // On annule la transaction
    Showmessage('Erreur : ' + E.Message);
  end;
end;

Juste une remarque en passant.

Pourquoi faire un Drop de la table et la recréer au lieu de faire simplement un delete de cette dernière ?

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
 
AdoConnection1.BeginTrans;
With TAdoQuery.Create(Self) do
try
  try
    Close;
    SQL.Clear;
    SQL.Add('Delete from ETIQUETTES');
    ExecSQL;
    AdoConnection1.CommitTrans;
  Except on E:Exception do
    AdoConnection1.RollBackTrans;
  end;
finally
  Free;
end;

PS: Quoi que les transactions sont inutiles avec PARADOX car il ne les gère pas.

[ALWEBER]

Le BDE n'est rien d'autre qu'un ensemble de DLL et un outil de paramétrage.
ODBC utilise des DLL similaires. L'accès ADO avec ODBC vers des tables paradox ne te permet pas certains paramétrage de tables ce qui peut être gênant dans certain cas.

En ce qui concerne le format des tables Paradox il est protégé par brevet donc tous les outils de création de tables et d'ajout/modification/suppression d'enregistrement passent par des procédures développés par Borland dont nous n'avons pas le code source.

Rien ne t'empêche de faire un lot MSI si tu veux te décharger de l'installation des postes clients

[aityahia]

d'après le bout de code je vois qu'il est question d'une table pour un traitement temporaire, alors il est important de compacter ta base a chaque que vous quittez l'application par exemple sinon la taille de votre base ne cessera pas d'augmenter.

[Rayek]

Le BDE n'est rien d'autre qu'un ensemble de DLL et un outil de paramétrage.
ODBC utilise des DLL similaires. L'accès ADO avec ODBC vers des tables paradox ne te permet pas certains paramétrage de tables ce qui peut être gênant dans certain cas.

Le gros problème c'est que les DLL ODBC évolue contrairement aux BDE et il arrive parfois qu'il y ait enormement de problème de compatibilité avec les bases de données récentes.

Et puis depuis le temps, il existe beaucoup mieux et beaucoup plus fiable que paradox au niveau des bases de données.

[ALWEBER]

Malatar a écrit :

Et puis depuis le temps, il existe beaucoup mieux et beaucoup plus fiable que paradox au niveau des bases de données.

Si tu es si sûr de toi je suis prêt à faire un BenchMark.

[Rayek]

Malatar a écrit :


Si tu es si sûr de toi je suis prêt à faire un BenchMark.

Un benchMark sur quoi ?
Sur les temps de réponses ?
Sur la fiabilité ? (faudrat me dire comment faire la ^^)
Par rapport à quoi ?

[ALWEBER]

On pourrait imaginer un scénario, une structure de données normalisée et fournir les données de bases au format texte générée par un petit programme et une liste des opérations à réaliser.

[Rayek]

On pourrait imaginer un scénario, une structure de données normalisée et fournir les données de bases au format texte générée par un petit programme et une liste des opérations à réaliser.

C'est inutile, Pour du client serveur, il vaut mieux utiliser des bases de données faites pour cela.

Paradox, c'est bien sympa pour des applications locales simples, mais c'est à éviter pour des moyennes ou grosses applications surtout pour des applications Clients/serveurs

[ALWEBER]

Malatar a écrit
C'est inutile, Pour du client serveur, il vaut mieux utiliser des bases de données faites pour cela.
Paradox, c'est bien sympa pour des applications locales simples, mais c'est à éviter pour des moyennes ou grosses applications surtout pour des applications Clients/serveurs

Tu ne sais pas à côté de quoi tu passes ...