Martín: En SQL el campo está definido como int de longitud 4. En VFP
existe el campo entero de longitud 4. Las tablas que envié son exactamente
las que genera el SQLEXEC.
Pablo: con respecto a tu TIP, el CODEPAGE es 1252 y el VFP es en español,
aunque tratandose de campos numéricos no debería afectar (nunca descartar
nada).
Con respecto al cambio de versión será algo que tendré que evaluar con más
celeridad que lo que venía haciendo, sobre todo si persisten estos
inconvenientes.
Saludos
Fabricio A. Bridera
[EMAIL PROTECTED]
----- Original Message -----
*From:* Martín Salías <[EMAIL PROTECTED]>
*To:* GUFA List Member <[email protected]>
*Sent:* Tuesday, June 19, 2007 11:48 AM
*Subject:* [GUFA] Problema en select-sql
Hola, Fabricio.
El problema no está en el SQL, y obviamente hacer ese val(str(...)) no es
más que una solución oscura que no te garantiza mucho. Lo más probable es
que el error sea en como está haciendo el casting del campo en SQL Server.
Decime que tipo de datos tiene marcado la tabla en SQL Server, porque el
problema puede tener que ver con algún defecto en la conversión al Int en
VFP. De hecho, si es VFP 6, las tablas que mandaste no son el resultado de
tu consulta porque en VFP 6 no había Int como tipo de datos, si la memoria
no me falla.
Más allá de esto, Fabricio, como siempre recomiendo: migrá a a VFP 9.
Estás usando una versión que tiene miles (literalmente) de bugs arreglados,
más mucha funcionalidad nueva, y no hay ningún motivo fundamental para
quedarse. Las aplicaciones VFP 9 corren perfectamente en Win98 y no consumen
más recursos que VFP 6 (de hecho, en muchos casos consumen menos).
Saludos,
/ms
On 6/19/07, Fabricio (GUFA) <[EMAIL PROTECTED]> wrote:
>
> Martín: Me meto. El tema lo origino yo porque tengo una PC con VFP 6
> en W98 que ejecuta una serie de consultas sobre SQL2000 y genera una serie
> de cursores a partir de los cuales termino de armar una serie de resultados
> en VFP.
>
> El problema se me generó porque dependiendo los registros que hay en los
> cursores en algunas ocasiones me saca del resultado final algún registro
> determinado. Para el ejemplo que envié si la unión de los cursores en un
> SELECT-SQL hecho en VFP lo escribo
> select ...
> from CFactPend a inner join CDetIVA b;
> on a.DocId = b.DocId;
> ...
> me devuelve 147 registros y si hago val (str (a.DocId))= val (str (
> b.DocId)) me devuelve 148 como corresponde y como veo que les da a
> todos.
>
> El tema es que no encuentro cuál es la lógica o el seteo o qué cosa que
> genera ese resultado.
> El registro que no me sale a mí es el que tiene DocId 28177, registro 44
> de la tabla CFactPend.
>
> En principio al cambiar la forma de combinar los campos en el SELECT lo
> he solucionado, pero me genera mucha inseguridad en el hecho de asegurar que
> no vuelva a pasar. Por otro lado, ¿tendré que cambiar todos mis select-sql
> para que se combinen con val (str (...)) en vez de hacerlo directamente?
> cosa que no me llama la atención, pero si no soluciono el problema de raíz
> lo tendré que hacer.
>
> Gracias por cualquier comentario.
> Fabricio A. Bridera
> [EMAIL PROTECTED]
>
> ----- Original Message -----
> *From:* Martín Salías <[EMAIL PROTECTED]>
> *To:* GUFA List Member <[email protected]>
> *Sent:* Tuesday, June 19, 2007 10:22 AM
> *Subject:* [GUFA] Problema en select-sql
>
> Hola,OZ.
>
> Los corrí y los miré. Ambos queries son exactamente iguales, dado que
> los valores posibles para DocId en uno y otro son numéricos. El query que
> hace el val del str no tiene sentido, ya que el campo es numérico en ambas
> tablas.
>
> ¿Qué se supone que están buscando? Perdón por haberme perdido el
> planteo. ¿Alguien me puede poner al tanto? OZ, podés mandarme algo derecho a
> mi para no hacer ruido en la lista si no vale la pena.
>
> Saludos,
> /ms
>
>
>
> On 6/19/07, Oscar Zárate <[EMAIL PROTECTED]> wrote:
> >
> > A ver muchachotes!!!!
> >
> > Alguno mas que corra el PRG, please. (lo atacho por si no lo tienen)
> >
> > Gracias a la banda.
> >
> >
> > On 6/19/07, Fabricio (GUFA) <[EMAIL PROTECTED] > wrote:
> > > Oscar: Gracias por investigar lo que puedas. Para mí también es
> > extraño y
> > > lamentablemente me deja con más dudas que certezas, ya que no puedo
> > asegurar
> > > que el problema no vuelva a darse en otras circunstancias.
> > >
> > > Con respecto a la naturaleza de las tablas, son las reales (con los
> > datos
> > > cambiados descriptivos obviamente). No tienen índices. Son
> > cursores
> > > creados con SQLEXEC luego de leer tablas en SQL 2000.
> > >
> > > Hubiera sido útil si alguien más probara el prg para ver si alguien
> > más
> > > reproducía el error o es sólo un problema de PC.
> > >
> > > Saludos
> > > Fabricio A. Bridera
> > > [EMAIL PROTECTED]
> > > ----- Original Message -----
> > > From: "Oscar Zárate" <[EMAIL PROTECTED]>
> > > To: "GUFA List Member" < [email protected]>
> > > Sent: Friday, June 15, 2007 8:54 PM
> > > Subject: [GUFA] Problema en select-sql
> > >
> > >
> > > Pablo, GRACIAS por meterte.
> > >
> > > Fabricio, no le encuentro nada. Es muy extranio. Podrias agregarle
> > un
> > > indice y relacionar las tablas y pararte en ese registro?
> > >
> > > Las tablas son las del ejemplo, no? No son otras? Las otras ... no
> > > tienen indices? Porque lo unico que se me ocurre es que tengas un
> > > indice corrupto y por eso al cambiar el algoritmo anda, pero asi ...
> > > en tablas planas sin indices donde el motor tiene que leer todos los
> > > registros ... no le veo nada.
> > >
> > > SaludOZ,
> > >
> > > On 6/16/07, Fabricio (GUFA) <[EMAIL PROTECTED]> wrote:
> > > > Oscar: El registro que no me sale es el que tiene DocId 28177,
> > registro
> > > 44
> > > > de la tabla CFactPend.
> > > > Pablo: Probé de borrar foxuser.* y volvera entrar a VFP y sigue
> > igual.
> > > >
> > > > Fabricio A. Bridera
> > > > [EMAIL PROTECTED]
> > > > ----- Original Message -----
> > > > From: "Oscar Zárate" <[EMAIL PROTECTED]>
> > > > To: "GUFA List Member" <[email protected] >
> > > > Sent: Friday, June 15, 2007 11:37 AM
> > > > Subject: [GUFA] Problema en select-sql
> > > >
> > > >
> > > > ok,
> > > >
> > > > No encuentro la forma que te de 147.
> > > >
> > > > select distinct a.DocId, CodPro, TipoComp, Letra, Suc, Nro,
> > FecEmision,;
> > > > RazonSoc, CUIT, Moneda, Monto, Imp1;
> > > > from CFactPend a inner join CDetIVA b;
> > > > on a.DocId = b.DocId ;
> > > > order by CodPro, FecEmision, TipoComp, Letra, Suc, Nro
> > > >
> > > >
> > > > Siempre da 148. Podes extraer cual es el registro que no esta en
> > el
> > > > otro ... hace el select de lo que no esta en el otro select (148
> > en
> > > > 147 .... va a faltar uno ... contame cual es ese uno).
> > > >
> > > > No encuentro la forma que de 147.
> > > >
> > > > Saludos,
> > > >
> > > > PS: Hay algo mas que vos estas haciendo y no es exactamente el
> > ejemplo?
> > > >
> > > >
> > > >
> > > > On 6/14/07, Oscar Zárate <[EMAIL PROTECTED]> wrote:
> > > > > Che mostro,
> > > > >
> > > > > me da con los dos 148 registros,
> > > > >
> > > > > select distinct a.DocId, CodPro, TipoComp, Letra, Suc, Nro,
> > > FecEmision,;
> > > > > RazonSoc, CUIT, Moneda, Monto, Imp1;
> > > > > from CFactPend a inner join CDetIVA b;
> > > > > on a.DocId = b.DocId;
> > > > > order by CodPro, FecEmision, TipoComp, Letra, Suc, Nro
> > > > >
> > > > > igual que con
> > > > >
> > > > > select distinct a.DocId, CodPro, TipoComp, Letra, Suc, Nro,
> > FecEmision,;
> > > > > RazonSoc, CUIT, Moneda, Monto, Imp1;
> > > > > from CFactPend a inner join CDetIVA b;
> > > > > on val (str ( a.DocId))= val (str (b.DocId));
> > > > > order by CodPro, FecEmision, TipoComp, Letra, Suc, Nro
> > > > >
> > > > > Podes mandar la lista de sets que tenes.
> > > > >
> > > > >
> > > > > Algo MUY raro pasa ... esta bien que nos de diferencia en el
> > tiempo
> > > > > que tarda (jajaja) pero no en la cantidad de resultados .... hay
> > > > > alguno mas que tenga el numero .. Martin aporta asi la gente se
> > > > > prende (hahaha),
> > > > >
> > > > > Saludos,
> > > > >
> > > > > On 6/13/07, Fabricio (GUFA) <[EMAIL PROTECTED]> wrote:
> > > > > > Adjunto un prg con la consulta que da el problema. Es una
> > consulta
> > > que
> > > > une
> > > > > > un archivo de facturas con otro donde está el IVA
> > correspondiente a
> > > cada
> > > > > > una. Se supone que toda Factura tiene un registro en la otra
> > tabla,
> > > > aunque
> > > > > > más no sea en 0. No pasa por ahí el problema.
> > > > > >
> > > > > > Hay 2 facturas de un proveedor llamado ERROR.
> > > > > >
> > > > > > Si en el select-sql la cláusula para combinar las tablas se
> > ponde val
> > > > (str
> > > > > > (a.DocID))= val (str (b.DocID)) funciona OK.
> > > > > > Si uno coloca a.DocID= b.DocID directamente hay 1 de esas 2
> > facturas
> > > que
> > > > no
> > > > > > la toma.
> > > > > >
> > > > > > Espero comentarios
> > > > > > Fabricio A. Bridera
> > > > > > [EMAIL PROTECTED]
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Oscar Zárate" < [EMAIL PROTECTED]>
> > > > > > To: "GUFA List Member" <[email protected]>
> > > > > > Sent: Tuesday, June 12, 2007 8:55 AM
> > > > > > Subject: [GUFA] Problema en select-sql
> > > > > >
> > > > > >
> > > > > > Podes mandar ejemplos?
> > > > > >
> > > > > > No es razonable.
> > > > > >
> > > > > > SaludOZ,
> > > > > >
> > > > > > On 6/12/07, Fabricio (GUFA) <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Reenvío este problema ya que sigo sin encontrar una
> > explicación
> > > > segura.
> > > > > > > Hasta ahora lo estoy haciendo andar con prueba y
> > error. Pero es
> > > hasta
> > > > que
> > > > > > > sale un nuevo caso y no me toma algún registro y siempre
> > tengo que
> > > ir
> > > > a
> > > > > > > tocar el select-sql y núnca sé si será la última vez.
> > > > > > >
> > > > > > > Fabricio A. Bridera
> > > > > > > [EMAIL PROTECTED]
> > > > > > > ----- Original Message -----
> > > > > > > From: Fabricio (GUFA)
> > > > > > > To: [email protected]
> > > > > > > Sent: Tuesday, May 22, 2007 8:44 AM
> > > > > > > Subject: Problema en select-sql
> > > > > > >
> > > > > > > Hola a todos, tengo el siguiente problema.
> > > > > > >
> > > > > > > Desde VFP hago una serie de consultas a una BD en SQL
> > 2000. Los
> > > > campos
> > > > > > > código los genera como enteros en las dbf del resultado de
> > la
> > > > consulta.
> > > > > > >
> > > > > > > Luego, ya trabajando en VFP desconectado de SQL, hago un
> > select como
> > > > el
> > > > > > que
> > > > > > > sigue:
> > > > > > >
> > > > > > > select Cursor1.Id1, Cursor1.Desc1, Cursor2.Desc2;
> > > > > > > from Cursor1, Cursor2;
> > > > > > > where Cursor1.Id1= Cursor2.Id1;
> > > > > > > into cursor NuevoCursor
> > > > > > >
> > > > > > > donde obviamente el campo Id1 sirve para relacionar ambos
> > cursores.
> > > > Ambos
> > > > > > > campos con numéricos enteros.
> > > > > > >
> > > > > > > El problema es que a veces (no siempre) algunos registros
> > que
> > > > coinciden en
> > > > > > > el campo Id1 no los trae. Primero probé en vez de
> > Cursor1.Id1=
> > > > > > Cursor2.Id1,
> > > > > > > lo cambié por val (str (Cursor1.Id1))= val (str (Cursor2.Id1))
> > y me
> > > > > > > funcionó. Pero después me saltó un caso que si lo proceso
> > con
> > > muchos
> > > > > > > registros más no lo toma y si lo proceso solo, sí. Por
> > último probé
> > > > > > cambiar
> > > > > > > el select por lo siguiente:
> > > > > > >
> > > > > > > select Cursor1.Id1, Cursor1.Desc1, Cursor2.Desc2;
> > > > > > > from Cursor1 inner join Cursor2;
> > > > > > > on val (str (Cursor1.Id1))= val (str (Cursor2.Id1));
> > > > > > > into cursor NuevoCursor
> > > > > > >
> > > > > > > Con este último cambio funcionó.
> > > > > > >
> > > > > > > De todos modos me queda la duda por qué me da problemas con
> > los
> > > casos
> > > > > > > anteriores.
> > > > > > >
> > > > > > > ¿Alguien tiene alguna idea?
> > > > > > >
> > > > > > > Saludos
> > > > > > > Fabricio A. Bridera
> > > > > > > [EMAIL PROTECTED]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
> --
> Martín Salías
> www.Salias.com.ar
> Agile Alliance Member - Microsoft MVP
>
>
--
Martín Salías
www.Salias.com.ar
Agile Alliance Member - Microsoft MVP
