Bonjour,
Que pensez vous!!?
J'ai un projet qui utilise Bde (paradox) j'aimerai passer a une soluc
plus stable et en multi-user.

un seul mot: firebird

/_Ameno_ a utilisé son clavier pour écrire/ :
> Bonjour,
> Que pensez vous!!?
> J'ai un projet qui utilise Bde (paradox) j'aimerai passer a une soluc plus
> stable et en multi-user.

--
Faust
"Une âme en peine peut en cacher une autre"

Pas forcément. Pour migrer une application fonctionnant avec une base de
données Paradox, il peut être plus "efficient" d'utiliser un format plus
récent, mais utilisant les mêmes logiques dans les composants... Ca
simplifie le travail, et ça ne demande pas de repenser complètement
l'application. Par exemple, pour migrer depuis Paradox vers DBIsam, il
suffit juste de deux étapes : 1) Migrer les tables avec l'assistant de
migration, fourni avec DBIsam... et 2) Renommer tous les composants d'accès
aux données en ajoutant "TDBIsam" devant chaque type. C'est pour ainsi dire
presqu'aussi simple que cela... (presque... il peut y avoir des détails
chiants dans les champs si le développeur s'est amusé à utiliser des
spécificités merdiques de Paradox).

Je dis cela parce que les accès à FireBird avec un TTable peuvent être
catastrophiques...

Faust <miss.me@no.where.invalid>
:: un seul mot: firebird
::
:: /_Ameno_ a utilisé son clavier pour écrire/ :
::: Bonjour,
::: Que pensez vous!!?
::: J'ai un projet qui utilise Bde (paradox) j'aimerai passer a une
::: soluc plus stable et en multi-user.
::
:: --
:: Faust
:: "Une âme en peine peut en cacher une autre"

> Je dis cela parce que les accès à FireBird avec un TTable peuvent être
> catastrophiques...


quoi ?

je dois migrer bientôt un projet de paradox vers firebird (que je n'ai
jamais utilisé jusqu'ici) et tu nous dis qu'il y a des problèmes ?

lesquels ? comment les éviter ? la meilleure façon de faire ?

merci de toute info supplémentaire

inconnu a écrit :
>
>
>> Je dis cela parce que les accès à FireBird avec un TTable peuvent être
>> catastrophiques...
>
>
> quoi ?
>
> je dois migrer bientôt un projet de paradox vers firebird (que je n'ai
> jamais utilisé jusqu'ici) et tu nous dis qu'il y a des problèmes ?
>
> lesquels ? comment les éviter ? la meilleure façon de faire ?
>
> merci de toute info supplémentaire

Ce sont les "problèmes" habituels d'un passage d'une base "fichier" à
une base C/S. Si tu charges une table de 50000 enregistrements dans un
DBGrid, ça va ramer... Enfin... Le serveur va râler, et en fonction des
composants que tu utilises, ça risque aussi d'être très lourd côté
client. Paradox était conçu pour fonctionner de la sorte... mais le
Client/Serveur, il n'est pas conçu pour ça.

BigGrizzly schrieb:
> inconnu a écrit :
>>
>>
>>> Je dis cela parce que les accès à FireBird avec un TTable peuvent être
>>> catastrophiques...
>>
>>
>> quoi ?
>>
>> je dois migrer bientôt un projet de paradox vers firebird (que je n'ai
>> jamais utilisé jusqu'ici) et tu nous dis qu'il y a des problèmes ?
>>
>> lesquels ? comment les éviter ? la meilleure façon de faire ?
>>
>> merci de toute info supplémentaire
>
> Ce sont les "problèmes" habituels d'un passage d'une base "fichier" à
> une base C/S. Si tu charges une table de 50000 enregistrements dans un
> DBGrid, ça va ramer... Enfin... Le serveur va râler, et en fonction des
> composants que tu utilises, ça risque aussi d'être très lourd côté
> client. Paradox était conçu pour fonctionner de la sorte... mais le
> Client/Serveur, il n'est pas conçu pour ça.
Pour être plus précis (voir pédant:

Travailler avec une RDBMS comme Firebird, Oracl, SQL Server... nécessite
de changer ses (mauvaises) habitudes.
Entre autres choses:

=> TTable est (au moins dans la plupart des cas) à bannir! TQuery & Co.
sont à favoriser. Pourquoi? Parcequ'une table sert principalement à
contenir des données "brutes". Les queries, Stored Procedures et autres
Views sont chargées de préparer/transformer les données nécessaires aux
logiciels clients.

=> il faut éviter (autant que faire se peut) d'afficher des Grids
interminables.

=> il faut bien étudier/penser les indexes que l'on souhaite intégrer à
la base: certains peuvent être vraiment contra-productifs, d'autres font
des miracles.

La migration Paradox -> Firebird est en soi assez simple / non
problématique.
C'est l'optimisation (le respect des règles ci-dessus, entre autres) qui
demande le plus d'efforts