alors qui de oracle ou toi a raison ? oracle n'a pas ete capable de
migrer
une base pick universe sur oracle donc soit tu as raison et les gens d'oracle sont incompetent ou tu as tord
Tu poses les mauvaises questions: les gars d'Oracle sont spécialistes... Orcale (qui l'eut cru). Donc ils sont a priori spécialistes pour mettre en place des solutions Oracle, pas pour faire des migrations, dans quel que sens que ce soit.
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des spécialistes Pick, les seconds extrayant les données dans un format gérable par les premiers, c'est une évidence idiote.
Mais ne t'en fait pas, des sociétés font cela très bien: http://www.pixieware.com/mvtosql.htm "PixieEditor
* Provides an easy-to-use GUI format with its own Windows front-end that connects to several different MV's. * Has the ability to extract data and send it directly to SQL-Server, MySQL, MS Access or a Windows text file."
je te signale que je vois mal pixie venir du canada
http://www.mvmigration.com/
" Based in the UK, we're happy to accept enquiries from Europe, the United States, Australia & New Zealand."
Sinon, en cherchant mieux qu'en 5 minutes sur Google, on doit pouvoir trouver une société française qui fait la même chose.
"Jerome Lambert" <jerome.lambert@swing.be> a écrit dans le message de
news:3ptc1nFc62q0U1@individual.net...
alors qui de oracle ou toi a raison ? oracle n'a pas ete capable de
migrer
une base pick universe sur oracle donc soit tu as raison et les gens
d'oracle sont incompetent ou tu as tord
Tu poses les mauvaises questions: les gars d'Oracle sont spécialistes...
Orcale (qui l'eut cru). Donc ils sont a priori spécialistes pour mettre
en place des solutions Oracle, pas pour faire des migrations, dans quel
que sens que ce soit.
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des
spécialistes Pick, les seconds extrayant les données dans un format
gérable par les premiers, c'est une évidence idiote.
Mais ne t'en fait pas, des sociétés font cela très bien:
http://www.pixieware.com/mvtosql.htm
"PixieEditor
* Provides an easy-to-use GUI format with its own Windows front-end
that connects to several different MV's.
* Has the ability to extract data and send it directly to
SQL-Server, MySQL, MS Access or a Windows text file."
je te signale que je vois mal pixie venir du canada
http://www.mvmigration.com/
" Based in the UK, we're happy to accept enquiries from Europe, the
United States, Australia & New Zealand."
Sinon, en cherchant mieux qu'en 5 minutes sur Google, on doit pouvoir
trouver une société française qui fait la même chose.
alors qui de oracle ou toi a raison ? oracle n'a pas ete capable de
migrer
une base pick universe sur oracle donc soit tu as raison et les gens d'oracle sont incompetent ou tu as tord
Tu poses les mauvaises questions: les gars d'Oracle sont spécialistes... Orcale (qui l'eut cru). Donc ils sont a priori spécialistes pour mettre en place des solutions Oracle, pas pour faire des migrations, dans quel que sens que ce soit.
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des spécialistes Pick, les seconds extrayant les données dans un format gérable par les premiers, c'est une évidence idiote.
Mais ne t'en fait pas, des sociétés font cela très bien: http://www.pixieware.com/mvtosql.htm "PixieEditor
* Provides an easy-to-use GUI format with its own Windows front-end that connects to several different MV's. * Has the ability to extract data and send it directly to SQL-Server, MySQL, MS Access or a Windows text file."
je te signale que je vois mal pixie venir du canada
http://www.mvmigration.com/
" Based in the UK, we're happy to accept enquiries from Europe, the United States, Australia & New Zealand."
Sinon, en cherchant mieux qu'en 5 minutes sur Google, on doit pouvoir trouver une société française qui fait la même chose.
professeur Méphisto (Christian)
helios a écrit :
si pick avait 10a de retard il y a 40a quel systeme etait similaire en 1955 ?
le boulier. Remarque que pour administrer un boulier, un boulet fait très bien l'affaire.
helios a écrit :
si pick avait 10a de retard il y a 40a quel systeme etait similaire en
1955 ?
le boulier.
Remarque que pour administrer un boulier, un boulet fait très
bien l'affaire.
"professeur Méphisto (Christian)" a écrit dans le message de news:
si pick avait 10a de retard il y a 40a quel systeme etait similaire en 1955 ?
le boulier. Remarque que pour administrer un boulier, un boulet fait très bien l'affaire.
alcool ? drogue ? folie?
"professeur Méphisto (Christian)" <professeur.mephisto@wanadouille.fr> a
écrit dans le message de
news:pan.2005.09.27.17.02.36.503863@wanadouille.fr...
si pick avait 10a de retard il y a 40a quel systeme etait similaire en
1955 ?
le boulier.
Remarque que pour administrer un boulier, un boulet fait très
bien l'affaire.
"professeur Méphisto (Christian)" a écrit dans le message de news:
si pick avait 10a de retard il y a 40a quel systeme etait similaire en 1955 ?
le boulier. Remarque que pour administrer un boulier, un boulet fait très bien l'affaire.
alcool ? drogue ? folie?
Blaise Potard
Jerome Lambert wrote:
"Jerome Lambert" a écrit dans le message de news:
"Jerome Lambert" a écrit dans le message de news:
"Jerome Lambert" a écrit dans le message de news:
helios a écrit : (...)
mais bien sur tout les migrations impossibles MULTIVALUE versSINGLEVALUEsont le fait d'incompetents
A partir du moment où j'ai des exemples de migrations parfaitement réussies, c'est que le facteur bloquant est humain et non technique...
non tes exemples de migration ne prouvent pas que toute les migrations sont techniquement possible mais que certaines le sont
si tu utilises une base multivalue en singlevalue il y a aucun probleme technique pour migrer
Non, je te rassure (en fait, je crois plutot que ça ne te rassure pas), les bases étaient utilisées en multivalue, et la migration a été possible...
alors qui de oracle ou toi a raison ? oracle n'a pas ete capable de migrer une base pick universe sur oracle donc soit tu as raison et les gens d'oracle sont incompetent ou tu as tord
Tu poses les mauvaises questions: les gars d'Oracle sont spécialistes... Orcale (qui l'eut cru). Donc ils sont a priori spécialistes pour mettre en place des solutions Oracle, pas pour faire des migrations, dans quel que sens que ce soit.
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des spécialistes Pick, les seconds extrayant les données dans un format gérable par les premiers, c'est une évidence idiote.
...Mais ce n'est pas forcément suffisant. En l'occurence, il me paraît évident que dans certains cas, la migration ne pourra pas se faire de façon satisfaisante sans repenser en grande partie l'architecture de la base, ce que ne peut pas forcément se permettre la boîte. Il me semble certain qu'une migration automatique d'une base multivaluée vers une base relationnelle normale fera une base potentiellement beaucoup plus grosse (mais avec des accès probablement plus rapide), et réciproquement faire une *vraie* migration vers pick pourrait faire gagner de la place.
Évidemment, ce que préconise helios (faire fonctionner pick comme une base relationnelle classique) est complètement con : on cumule les inconvénients des deux mondes ; un accès *forcément* plus lent qu'avec une vraie base relationnelle, et une taille sensiblement identique de la base. Bref, une "migration" qui n'en est pas une et qui ne sert strictement à rien.
Jerome Lambert wrote:
"Jerome Lambert" <jerome.lambert@swing.be> a écrit dans le message de
news:3pt8gfFc5ronU1@individual.net...
"Jerome Lambert" <jerome.lambert@swing.be> a écrit dans le message de
news:3pt6pfFc52j0U1@individual.net...
"Jerome Lambert" <jerome.lambert@swing.be> a écrit dans le
message de news:3pt4rhFc3iovU1@individual.net...
helios a écrit : (...)
mais bien sur tout les migrations impossibles MULTIVALUE
versSINGLEVALUEsont le fait d'incompetents
A partir du moment où j'ai des exemples de migrations parfaitement
réussies, c'est que le facteur bloquant est humain et non
technique...
non tes exemples de migration ne prouvent pas que toute les
migrations sont techniquement possible mais que certaines le sont
si tu utilises une base multivalue en singlevalue il y a aucun
probleme technique pour migrer
Non, je te rassure (en fait, je crois plutot que ça ne te rassure pas),
les bases étaient utilisées en multivalue, et la migration a été
possible...
alors qui de oracle ou toi a raison ? oracle n'a pas ete capable de
migrer
une base pick universe sur oracle donc soit tu as raison et les gens
d'oracle sont incompetent ou tu as tord
Tu poses les mauvaises questions: les gars d'Oracle sont spécialistes...
Orcale (qui l'eut cru). Donc ils sont a priori spécialistes pour mettre
en place des solutions Oracle, pas pour faire des migrations, dans quel
que sens que ce soit.
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des
spécialistes Pick, les seconds extrayant les données dans un format
gérable par les premiers, c'est une évidence idiote.
...Mais ce n'est pas forcément suffisant. En l'occurence, il me paraît
évident que dans certains cas, la migration ne pourra pas se faire de
façon satisfaisante sans repenser en grande partie l'architecture de la
base, ce que ne peut pas forcément se permettre la boîte. Il me semble
certain qu'une migration automatique d'une base multivaluée vers une
base relationnelle normale fera une base potentiellement beaucoup plus
grosse (mais avec des accès probablement plus rapide), et réciproquement
faire une *vraie* migration vers pick pourrait faire gagner de la place.
Évidemment, ce que préconise helios (faire fonctionner pick comme une
base relationnelle classique) est complètement con : on cumule les
inconvénients des deux mondes ; un accès *forcément* plus lent qu'avec
une vraie base relationnelle, et une taille sensiblement identique de la
base. Bref, une "migration" qui n'en est pas une et qui ne sert
strictement à rien.
mais bien sur tout les migrations impossibles MULTIVALUE versSINGLEVALUEsont le fait d'incompetents
A partir du moment où j'ai des exemples de migrations parfaitement réussies, c'est que le facteur bloquant est humain et non technique...
non tes exemples de migration ne prouvent pas que toute les migrations sont techniquement possible mais que certaines le sont
si tu utilises une base multivalue en singlevalue il y a aucun probleme technique pour migrer
Non, je te rassure (en fait, je crois plutot que ça ne te rassure pas), les bases étaient utilisées en multivalue, et la migration a été possible...
alors qui de oracle ou toi a raison ? oracle n'a pas ete capable de migrer une base pick universe sur oracle donc soit tu as raison et les gens d'oracle sont incompetent ou tu as tord
Tu poses les mauvaises questions: les gars d'Oracle sont spécialistes... Orcale (qui l'eut cru). Donc ils sont a priori spécialistes pour mettre en place des solutions Oracle, pas pour faire des migrations, dans quel que sens que ce soit.
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des spécialistes Pick, les seconds extrayant les données dans un format gérable par les premiers, c'est une évidence idiote.
...Mais ce n'est pas forcément suffisant. En l'occurence, il me paraît évident que dans certains cas, la migration ne pourra pas se faire de façon satisfaisante sans repenser en grande partie l'architecture de la base, ce que ne peut pas forcément se permettre la boîte. Il me semble certain qu'une migration automatique d'une base multivaluée vers une base relationnelle normale fera une base potentiellement beaucoup plus grosse (mais avec des accès probablement plus rapide), et réciproquement faire une *vraie* migration vers pick pourrait faire gagner de la place.
Évidemment, ce que préconise helios (faire fonctionner pick comme une base relationnelle classique) est complètement con : on cumule les inconvénients des deux mondes ; un accès *forcément* plus lent qu'avec une vraie base relationnelle, et une taille sensiblement identique de la base. Bref, une "migration" qui n'en est pas une et qui ne sert strictement à rien.
helios
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des spécialistes Pick, les seconds extrayant les données dans un format gérable par les premiers, c'est une évidence idiote.
...Mais ce n'est pas forcément suffisant. En l'occurence, il me paraît évident que dans certains cas, la migration ne pourra pas se faire de façon satisfaisante sans repenser en grande partie l'architecture de la base, ce que ne peut pas forcément se permettre la boîte. Il me semble certain qu'une migration automatique d'une base multivaluée vers une base relationnelle normale fera une base potentiellement beaucoup plus grosse (mais avec des accès probablement plus rapide), et réciproquement faire une *vraie* migration vers pick pourrait faire gagner de la place.
faux les acces sont plus rapide en multivalue qu'en singlevalue une des raisons de l'echec oracle etait que les acces oracle etait trop lent par rapport à pick universe
Évidemment, ce que préconise helios (faire fonctionner pick comme une base relationnelle classique) est complètement con : on cumule les inconvénients des deux mondes ; un accès *forcément* plus lent qu'avec une vraie base relationnelle, et une taille sensiblement identique de la base. Bref, une "migration" qui n'en est pas une et qui ne sert strictement à rien.
je ne preconise pas de faire fonctionne pick comme une base relationnelle classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des
spécialistes Pick, les seconds extrayant les données dans un format
gérable par les premiers, c'est une évidence idiote.
...Mais ce n'est pas forcément suffisant. En l'occurence, il me paraît
évident que dans certains cas, la migration ne pourra pas se faire de
façon satisfaisante sans repenser en grande partie l'architecture de la
base, ce que ne peut pas forcément se permettre la boîte. Il me semble
certain qu'une migration automatique d'une base multivaluée vers une
base relationnelle normale fera une base potentiellement beaucoup plus
grosse (mais avec des accès probablement plus rapide), et réciproquement
faire une *vraie* migration vers pick pourrait faire gagner de la place.
faux les acces sont plus rapide en multivalue qu'en singlevalue une des
raisons de l'echec oracle etait que les acces oracle etait trop lent par
rapport à pick universe
Évidemment, ce que préconise helios (faire fonctionner pick comme une
base relationnelle classique) est complètement con : on cumule les
inconvénients des deux mondes ; un accès *forcément* plus lent qu'avec
une vraie base relationnelle, et une taille sensiblement identique de la
base. Bref, une "migration" qui n'en est pas une et qui ne sert
strictement à rien.
je ne preconise pas de faire fonctionne pick comme une base relationnelle
classique mais pick en singlevalue est plus performant qu"une base
relationnelle classique donc cela serait qu'en meme avantageux de le faire
Ce qu'il aurait fallut, ce sont des spécialistes Oracle *et* des spécialistes Pick, les seconds extrayant les données dans un format gérable par les premiers, c'est une évidence idiote.
...Mais ce n'est pas forcément suffisant. En l'occurence, il me paraît évident que dans certains cas, la migration ne pourra pas se faire de façon satisfaisante sans repenser en grande partie l'architecture de la base, ce que ne peut pas forcément se permettre la boîte. Il me semble certain qu'une migration automatique d'une base multivaluée vers une base relationnelle normale fera une base potentiellement beaucoup plus grosse (mais avec des accès probablement plus rapide), et réciproquement faire une *vraie* migration vers pick pourrait faire gagner de la place.
faux les acces sont plus rapide en multivalue qu'en singlevalue une des raisons de l'echec oracle etait que les acces oracle etait trop lent par rapport à pick universe
Évidemment, ce que préconise helios (faire fonctionner pick comme une base relationnelle classique) est complètement con : on cumule les inconvénients des deux mondes ; un accès *forcément* plus lent qu'avec une vraie base relationnelle, et une taille sensiblement identique de la base. Bref, une "migration" qui n'en est pas une et qui ne sert strictement à rien.
je ne preconise pas de faire fonctionne pick comme une base relationnelle classique mais pick en singlevalue est plus performant qu"une base relationnelle classique donc cela serait qu'en meme avantageux de le faire
Richard Delorme
quel est deja la puissance de calcul d'un 68020 ?
De 2 à 4 bogomips. Ma machine à 2 sous atteint 3653.63 bogomips.
-- Richard
quel est deja la puissance de calcul d'un 68020 ?
De 2 à 4 bogomips.
Ma machine à 2 sous atteint 3653.63 bogomips.
