La base que je dois mettre en place deviendra par la suite consequente
et mon boss se proccupe, trop a mon gout, de savoir si Access
aura la puissance necessaire pour qu'elle puisse tourner correctement
malgré l'utilisation de 6 personnes en simulanée ?
En fait, La base serait a priori constituée de 4 modeles
identiques (pour 4 services differents = 3 personnes +1 +1) et en relation
entre eux par SQL, ca serait un moyen de reduire les données par base
et accessible par les services, mais est ce que ca rendra l'utilisation
du systeme plus souple et rapide, sachant que l'echange entre base
se fait assez rarement ?
Et derniere question, il est apparement certain que de faire une base
dorsale et des bases frontales est un tres bon moyen de diminuer le trafic
reseau et d'ameliorer sensiblement la velocité du truc, vrai ou faux ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jpaulin
On Sat, 06 Mar 2004 08:25:10 +0100, Marc Duteil wrote:
jpaulin a écrit :
Le point faible d'Access, c'est la gestion des données, pour le reste c'est plustot bien (personellement j'aime pas , mais il faut dire que c'est plustot bien quand meme).
As tu reflechi a l'option Base SQL (par exemple FireBird, mais ca peut etres bien etre autre chose) + Access pour l'affichage des données (tables attachées via ODBC) ???
tu as obligation d'acheter une licence Access par poste utilisateur? si tu tournes avec OpenOffice, ça fait assez cher la simple interface utilisateur. est-ce que je me trompe?
Le runtime Access est gratuit quend tu as un pack office PRO ...
On Sat, 06 Mar 2004 08:25:10 +0100, Marc Duteil wrote:
jpaulin a écrit :
Le point faible d'Access, c'est la gestion des données, pour le reste
c'est plustot bien (personellement j'aime pas , mais il faut dire que
c'est plustot bien quand meme).
As tu reflechi a l'option Base SQL (par exemple FireBird, mais ca peut
etres bien etre autre chose) + Access pour l'affichage des données (tables
attachées via ODBC) ???
tu as obligation d'acheter une licence Access par poste utilisateur?
si tu tournes avec OpenOffice, ça fait assez cher la simple interface
utilisateur.
est-ce que je me trompe?
Le runtime Access est gratuit quend tu as un pack office PRO ...
On Sat, 06 Mar 2004 08:25:10 +0100, Marc Duteil wrote:
jpaulin a écrit :
Le point faible d'Access, c'est la gestion des données, pour le reste c'est plustot bien (personellement j'aime pas , mais il faut dire que c'est plustot bien quand meme).
As tu reflechi a l'option Base SQL (par exemple FireBird, mais ca peut etres bien etre autre chose) + Access pour l'affichage des données (tables attachées via ODBC) ???
tu as obligation d'acheter une licence Access par poste utilisateur? si tu tournes avec OpenOffice, ça fait assez cher la simple interface utilisateur. est-ce que je me trompe?
Le runtime Access est gratuit quend tu as un pack office PRO ...
jpaulin
On Sat, 06 Mar 2004 11:17:05 +0100, Mooaa wrote:
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur d'etats pour Kylix.
On Sat, 06 Mar 2004 11:17:05 +0100, Mooaa wrote:
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la
portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur
d'etats pour Kylix.
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur d'etats pour Kylix.
Marc Collin
jpaulin wrote:
On Sat, 06 Mar 2004 11:17:05 +0100, Mooaa wrote:
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur d'etats pour Kylix.
regarde fortes report
-- Borland rulez http://pages.infinit.net/borland
jpaulin wrote:
On Sat, 06 Mar 2004 11:17:05 +0100, Mooaa wrote:
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la
portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur
d'etats pour Kylix.
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur d'etats pour Kylix.
regarde fortes report
-- Borland rulez http://pages.infinit.net/borland
Marc Collin
jpaulin wrote:
On Sat, 06 Mar 2004 11:17:05 +0100, Mooaa wrote:
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur d'etats pour Kylix.
ta fortes report et report manager
-- Borland rulez http://pages.infinit.net/borland
jpaulin wrote:
On Sat, 06 Mar 2004 11:17:05 +0100, Mooaa wrote:
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la
portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur
d'etats pour Kylix.
Mieux développez avec un "langage" style Delphi qu'avec Access.
C'est ce que fais: Base Firebird + client Delphi/Kylix (je confirme la portabilite Delphi/Kylix en mode CLX), il manque juste un bon generateur d'etats pour Kylix.
