Conversion datos de vfp a Sql 2005
138 views
Skip to first unread message
elkin dario uribe torres
Feb 10, 2011, 8:44:51 AM2/10/11
to publice...@googlegroups.com
Muy buenos dias
Para migrar una base de datos de visual foxpro a el motor de Sql Server 2005, cuales datos me aconsejan que pueda utilizar para los campos character de Vfp y para los campos numericos ejemplo:
Character
-Varchar
-Char
Numeric
-Float
-Decimal
La duda me asalta porque si utilizo la herramienta de importacion del sql 2005 el sugiere que estos campos sean con Char y Decimal respectivamente, y yo lo venia haciendo por Varchar y Float y asi es como tengo la tabla de equivalencia en el migrador.
lparameter campo
tipocampo=vartype(&campo)
do case
case vartype(&campo)='C'
auxtipo='varchar'
case vartype(&campo)='D'
auxtipo='datetime'
case vartype(&campo)='T'
auxtipo='datetime'
case vartype(&campo)='N'
auxtipo='float'
case vartype(&campo)='L'
auxtipo='bit'
endcase
Gracias
Elkin uribe
Para migrar una base de datos de visual foxpro a el motor de Sql Server 2005, cuales datos me aconsejan que pueda utilizar para los campos character de Vfp y para los campos numericos ejemplo:
Character
-Varchar
-Char
Numeric
-Float
-Decimal
La duda me asalta porque si utilizo la herramienta de importacion del sql 2005 el sugiere que estos campos sean con Char y Decimal respectivamente, y yo lo venia haciendo por Varchar y Float y asi es como tengo la tabla de equivalencia en el migrador.
lparameter campo
tipocampo=vartype(&campo)
do case
case vartype(&campo)='C'
auxtipo='varchar'
case vartype(&campo)='D'
auxtipo='datetime'
case vartype(&campo)='T'
auxtipo='datetime'
case vartype(&campo)='N'
auxtipo='float'
case vartype(&campo)='L'
auxtipo='bit'
endcase
Gracias
Elkin uribe
Hugo C.
Feb 10, 2011, 2:04:13 PM2/10/11
to Comunidad de Visual Foxpro en Español
Checa este articulo de Les Pinter (En ingles)
http://www.lespinter.com/ShowArticle.aspx?ArtNum=404
Busca ( PROCEDURE CreateTable )
Tal vez te ayude.
Saludos.
On 10 feb, 06:44, elkin dario uribe torres <eduribe2...@gmail.com>
wrote:
http://www.lespinter.com/ShowArticle.aspx?ArtNum=404
Busca ( PROCEDURE CreateTable )
Tal vez te ayude.
Saludos.
On 10 feb, 06:44, elkin dario uribe torres <eduribe2...@gmail.com>
wrote:
elkin dario uribe torres
Feb 10, 2011, 2:26:44 PM2/10/11
to publice...@googlegroups.com
Muchas gracias Hugo
Investigando un poco "Si defines un char(10) y un varchar(10) y en ambos escribes "hola", el campo char siempre va a pesar 10 bytes, pero varchar va a pesar 4.". Con este enunciado se iria uno por el varchar inmediatamente pero hay una salvedad y es "Cuando usas VARCHAR en una tabla (al igual que ciertas columnas creadas para grandes cantidades de texto y valores binarios) el ancho de cada fila se hace inconsistente. Una fila podría tener 40 bytes de longitud mientras que otra sólo 8. MySQL puede manejar esto almacenando la longitud de la fila en su sistema de archivos pero el servidor debe leer la longitud de cada fila antes de buscarla y continuar con la siguiente fila, donde deberá verificar la longitud otra vez, ad nauseam. Al definir campos de texto como CHAR ocuparemos más espacio en el disco rígido pero habrá un aumento en la velocidad ya que el servidor sabrá que cada una de las filas tiene exactamente el mismo tamaño (por ejemplo 120 bytes), permitiéndole que busque entre las filas sin verificar su longitud primero. Por tal motivo, recomiendo que definas tus campos de texto como CHAR para mejorar la performance de las consultas, a menos que el espacio de almacenamiento sea una consideración importante (y con los precios de los discos de hoy en día esta no es una gran preocupación, principalmente con nuestra aplicación)". Me quedo con los CHAR.
En lo referente a el campo Float y el Decimal, encontre lo siguiente "Creo que la comparación la gana el tipo de dato Decimal si necesitamos que se almacene la representación exacta de los números, ya que el tipo de dato float almacena una aproximación." y esto otro "Debido a la naturaleza aproximada de los tipos de datos float y real, no los use cuando necesite un comportamiento numérico exacto, como, por ejemplo, en aplicaciones financieras, en operaciones que conlleven un redondeo o en comprobaciones de igualdad. En su lugar, use los tipos de datos enteros, decimal, money o smallmoney".
Como la aplicacion que se esta migrando tiene que ver con el sector financiero y bancario acatare las recomendaciones del enunciado.
Gracias
Elkin uribe
Investigando un poco "Si defines un char(10) y un varchar(10) y en ambos escribes "hola", el campo char siempre va a pesar 10 bytes, pero varchar va a pesar 4.". Con este enunciado se iria uno por el varchar inmediatamente pero hay una salvedad y es "Cuando usas VARCHAR en una tabla (al igual que ciertas columnas creadas para grandes cantidades de texto y valores binarios) el ancho de cada fila se hace inconsistente. Una fila podría tener 40 bytes de longitud mientras que otra sólo 8. MySQL puede manejar esto almacenando la longitud de la fila en su sistema de archivos pero el servidor debe leer la longitud de cada fila antes de buscarla y continuar con la siguiente fila, donde deberá verificar la longitud otra vez, ad nauseam. Al definir campos de texto como CHAR ocuparemos más espacio en el disco rígido pero habrá un aumento en la velocidad ya que el servidor sabrá que cada una de las filas tiene exactamente el mismo tamaño (por ejemplo 120 bytes), permitiéndole que busque entre las filas sin verificar su longitud primero. Por tal motivo, recomiendo que definas tus campos de texto como CHAR para mejorar la performance de las consultas, a menos que el espacio de almacenamiento sea una consideración importante (y con los precios de los discos de hoy en día esta no es una gran preocupación, principalmente con nuestra aplicación)". Me quedo con los CHAR.
En lo referente a el campo Float y el Decimal, encontre lo siguiente "Creo que la comparación la gana el tipo de dato Decimal si necesitamos que se almacene la representación exacta de los números, ya que el tipo de dato float almacena una aproximación." y esto otro "Debido a la naturaleza aproximada de los tipos de datos float y real, no los use cuando necesite un comportamiento numérico exacto, como, por ejemplo, en aplicaciones financieras, en operaciones que conlleven un redondeo o en comprobaciones de igualdad. En su lugar, use los tipos de datos enteros, decimal, money o smallmoney".
Como la aplicacion que se esta migrando tiene que ver con el sector financiero y bancario acatare las recomendaciones del enunciado.
Gracias
Elkin uribe
Hugo C.
Feb 10, 2011, 3:05:48 PM2/10/11
to Comunidad de Visual Foxpro en Español
ok, Buenos puntos.
Saludos.
On 10 feb, 12:26, elkin dario uribe torres <eduribe2...@gmail.com>
wrote:
> > > Elkin uribe- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
Saludos.
On 10 feb, 12:26, elkin dario uribe torres <eduribe2...@gmail.com>
wrote:
> Muchas gracias Hugo
>
> Investigando un poco "Si defines un char(10) y un varchar(10) y en ambos
> escribes "hola", el campo char siempre va a pesar 10 bytes, pero varchar va
> a pesar 4.". Con este enunciado se iria uno por el varchar inmediatamente
> pero hay una salvedad y es "Cuando usas VARCHAR en una tabla (al igual que
> ciertas columnas creadas para grandes cantidades de texto y valores
> binarios) el ancho de cada fila se hace inconsistente. Una fila podría tener
> 40 bytes de longitud mientras que otra sólo 8. MySQL puede manejar esto
> almacenando la longitud de la fila en su sistema de archivos pero el
> servidor debe leer la longitud de cada fila antes de buscarla y continuar
> con la siguiente fila, donde deberá verificar la longitud otra vez, ad
> nauseam. Al definir campos de texto como CHAR ocuparemos más espacio en el
> disco rígido pero habrá un aumento en la velocidad ya que el servidor sabrá
> que cada una de las filas tiene exactamente el mismo tamaño (por ejemplo 120
> bytes), permitiéndole que busque entre las filas sin verificar su longitud
> primero. Por tal motivo, recomiendo que definas tus campos de texto como
> CHAR para mejorar la performance de las consultas, a menos que el espacio de
> almacenamiento sea una consideración importante (y con los precios de los
> discos de hoy en día esta no es una gran preocupación, principalmente con
> nuestra aplicación)". Me quedo con los CHAR.
>
> En lo referente a el campo Float y el Decimal, encontre lo siguiente "Creo
> que la comparación la gana el tipo de dato Decimal si necesitamos que se
> almacene la representación exacta de los números, ya que el tipo de dato
> float almacena una aproximación." y esto otro "*Debido a la naturaleza
>
> Investigando un poco "Si defines un char(10) y un varchar(10) y en ambos
> escribes "hola", el campo char siempre va a pesar 10 bytes, pero varchar va
> a pesar 4.". Con este enunciado se iria uno por el varchar inmediatamente
> pero hay una salvedad y es "Cuando usas VARCHAR en una tabla (al igual que
> ciertas columnas creadas para grandes cantidades de texto y valores
> binarios) el ancho de cada fila se hace inconsistente. Una fila podría tener
> 40 bytes de longitud mientras que otra sólo 8. MySQL puede manejar esto
> almacenando la longitud de la fila en su sistema de archivos pero el
> servidor debe leer la longitud de cada fila antes de buscarla y continuar
> con la siguiente fila, donde deberá verificar la longitud otra vez, ad
> nauseam. Al definir campos de texto como CHAR ocuparemos más espacio en el
> disco rígido pero habrá un aumento en la velocidad ya que el servidor sabrá
> que cada una de las filas tiene exactamente el mismo tamaño (por ejemplo 120
> bytes), permitiéndole que busque entre las filas sin verificar su longitud
> primero. Por tal motivo, recomiendo que definas tus campos de texto como
> CHAR para mejorar la performance de las consultas, a menos que el espacio de
> almacenamiento sea una consideración importante (y con los precios de los
> discos de hoy en día esta no es una gran preocupación, principalmente con
> nuestra aplicación)". Me quedo con los CHAR.
>
> En lo referente a el campo Float y el Decimal, encontre lo siguiente "Creo
> que la comparación la gana el tipo de dato Decimal si necesitamos que se
> almacene la representación exacta de los números, ya que el tipo de dato
> aproximada de los tipos de datos float y real, no los use cuando necesite un
> comportamiento numérico exacto, como, por ejemplo, en aplicaciones
> financieras, en operaciones que conlleven un redondeo o en comprobaciones de
> igualdad. En su lugar, use los tipos de datos enteros, decimal, money o
> smallmoney".
>
> *
> comportamiento numérico exacto, como, por ejemplo, en aplicaciones
> financieras, en operaciones que conlleven un redondeo o en comprobaciones de
> igualdad. En su lugar, use los tipos de datos enteros, decimal, money o
> smallmoney".
>
> Como la aplicacion que se esta migrando tiene que ver con el sector
> financiero y bancario acatare las recomendaciones del enunciado.
>
> Gracias
>
> Elkin uribe
>
> financiero y bancario acatare las recomendaciones del enunciado.
>
> Gracias
>
> Elkin uribe
>
>
> - Mostrar texto de la cita -
Arnaldo Toledano (GMail)
Feb 10, 2011, 3:54:20 PM2/10/11
to publice...@googlegroups.com
Exelente tu Aporte.
Gracias
Arnaldo
__________ Información de ESET NOD32 Antivirus, versión de la base de firmas de virus 5863 (20110210) __________
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
ESET NOD32 Antivirus ha comprobado este mensaje.
http://www.eset.com
Jairo Miranda
Feb 10, 2011, 5:08:12 PM2/10/11
to publice...@googlegroups.com
Buenas tardes ..
Alguien tiene un programa que maneje multibodega , o algo por el estilo,y si
saben sobre lo que significa Backorder, es decir el cliente ase un pedido
pero solo se le despacha la mitad porque la mercancía aun no había llegado a
puerto , así que queda pendiente la otra mitad , el sistema debe verificar
el despacho en el momento que llegue la mercancía para entonces enviar lo
que faltaba.
Alguien tiene un programa que maneje multibodega , o algo por el estilo,y si
saben sobre lo que significa Backorder, es decir el cliente ase un pedido
pero solo se le despacha la mitad porque la mercancía aun no había llegado a
puerto , así que queda pendiente la otra mitad , el sistema debe verificar
el despacho en el momento que llegue la mercancía para entonces enviar lo
que faltaba.
Alguna idea sea bienvenida
Jairo
Jose Zurita
Feb 10, 2011, 5:12:55 PM2/10/11
to PublicesvFoxpro
Esto mer ayudara al iniciar a pasar mis datos de Fox a SQL, gracias por tuaporte, muy interesante. FELICITACIONES
From: arnaldo....@gmail.com
To: publice...@googlegroups.com
From: arnaldo....@gmail.com
To: publice...@googlegroups.com
Subject: Re: [vfp] Re: Conversion datos de vfp a Sql 2005
Date: Thu, 10 Feb 2011 17:54:20 -0300
Nelson Martinez
Feb 10, 2011, 6:46:26 PM2/10/11
to publice...@googlegroups.com
Multibodega son varias ubicaciones para un mismo producto, para un mejor
desarrollo trabaje con bodegas y localizaciones. Por cada bodega varias
localizaciones.
Backorder es la cantidad pendiente por recibir, asuma de que pide 10 y solo
te mandan 3 el backorder es de 7
desarrollo trabaje con bodegas y localizaciones. Por cada bodega varias
localizaciones.
Backorder es la cantidad pendiente por recibir, asuma de que pide 10 y solo
te mandan 3 el backorder es de 7
-----Mensaje original-----
De: publice...@googlegroups.com
[mailto:publice...@googlegroups.com] En nombre de Jairo Miranda
Enviado el: jueves, 10 de febrero de 2011 05:08 p.m.
Para: publice...@googlegroups.com
Asunto: RE: [vfp] Re: Multibodega
Jairo Miranda
Feb 11, 2011, 8:41:58 AM2/11/11
to publice...@googlegroups.com
Gracias por aclarame el asunto .. eso es lo que quiero implementar..
Jairo
-----Mensaje original-----
De: publice...@googlegroups.com
[mailto:publice...@googlegroups.com] En nombre de Nelson Martinez
Enviado el: Jueves, 10 de Febrero de 2011 18:46
Jairo Miranda
Feb 11, 2011, 8:46:52 AM2/11/11
to publice...@googlegroups.com
La idea sería .
Maestro de productos . Idproducto, CodigoProducto, Idbodega, Idubicacion
Maestro de bodegas . IDBodega , códigoBodega, detallebodega
Tabla de ubicaciones . Idubicacion, Iddetalleubocacion.
Relación por referencia, bodega y ubicación.
jairo
-----Mensaje original-----
De: publice...@googlegroups.com
[mailto:publice...@googlegroups.com] En nombre de Nelson Martinez
Enviado el: Jueves, 10 de Febrero de 2011 18:46
Reply all
Reply to author
Forward
0 new messages