Optimizar SQL2000

Insisto, no se como trabaja VFP, pero en mi codigo y procedimientos algo que
me agiliza TREMENDAMENTE las consultas es utilizar NEXTRECORDSET.


Si tengo que cargar cinco combos en un formulario, lo normal es realizar
cinco conexiones y que me devuelvan cinco objetos, pero con el NEXTRECORDSET
solo realizo una sola consulta y me trae todos esos datos en una sola
conexion y en un solo recodset (o dataset). Cuando optimizo?, bueno, no lo
sabran hasta que hagan la prueba. Ojala se pueda hacer el VFP.

Seria algo asi

create procedure usp_Multiplesconsultas
as
begin
select a,b,c,d from WWW;
select a,b,c,d from XXX;
select a,b,c,d from YYY;
select a,b,c,d from ZZZ;
end

y en tu codigo

abres conexion
defines recordset o dataset o datareader
cargas el primer resultado (select a,b,c,d from WWW)
lo procesas
NEXTRECORDSET
cargas el segundo resultado (select a,b,c,d from XXX)
lo procesas
NEXTRECORDSET
.
.
.
.cargas el ultimo resultado (select a,b,c,d from ZZZ;)
lo procesas
cierras conexion
eliminas objetos


ByteMad





"Jose Camacho Vaca" escribió en
el mensaje news:

Muchas gracias a todos por sus respuestas. Bueno, antes que nada, parece
que
de manera definitiva voy a tener que migrar a otra arquitectura. Primero,
el
volumen de datos no es tanto el problema, sino el trafico que hay en la
red,
normalmente un proceso implica lo siguiente:
Dame el No. de cliente.
Dame el detalle de la cuenta del cliente.
Dame los abonos del renglón 5 del detalle.
Dame los documentos del primer abono
y volvemos al primer paso.
Lo malo como pueden ver es que hay mucho trafico de ida y vuelta, no es
mucho con lo que se trafica, pero si muchas veces y eso multiplicado por
el
No. de equipos hace lenta la conexión.
Al parecer la solución va a ser ASP o algo por el estilo.
De todas formas cualquier sugerencia adicional va a ser bien recibida.
Gracias nuevamente y saludos.
José Camacho Vaca
Colima, MX


"Jose Camacho Vaca" wrote:

Una consulta, por razones de presupuesto tenemos conexion muy lentas a
nuestro servidor SQL, hasta 3 maquinas enlazadas sobre una conexion de
64kbps. Obviamente todo eso nos esta perjudicando en la velocidad de
nuestra
aplicación principal que es de tipo OnLine. Las características
generales
del sistema y de la infraestructura son las siguientes: servidor HP
Proliant
ML370 1Gb. RAM 3 DD SCSI de 40 Gb. (no estan en RAID),
SmallBussinessServer2003, SQL-Server2000, se conectan hasta 40 terminales
simultáneamente. Nuestra apliacion esta hecha en VFP8, usa SQLPassThroug
bastante optimizado, todos los equipos terminales tienen WinXP-Pro con
256 de
memoria. Los que se conectan a la red local por medio de cable no tienen
ningún problema, pero los que se conectan por medio de un enlace de linea
dedicada de 64 Kbps, se vuelven muy lentos.
Cualquier sugerencia será bien recibida, mucha gracias.
Saludos.
José Camacho Vaca
Colima, MX

yo programo en VFP y para ese caso yo mejor hago un solo procedimiento y
en el hago las uniones de las tablas que necesito para los respectivos
combos
y luego en el formulario antes de que el usuario seleccione un elemento de
la lista del combo filtro el resultado por los datos que corresponden a ese
combo, y es bien eficiente.

saludos.

"Fernando Fauche G." escribió en el mensaje
news:%

Insisto, no se como trabaja VFP, pero en mi codigo y procedimientos algo
que me agiliza TREMENDAMENTE las consultas es utilizar NEXTRECORDSET.


Si tengo que cargar cinco combos en un formulario, lo normal es realizar
cinco conexiones y que me devuelvan cinco objetos, pero con el
NEXTRECORDSET solo realizo una sola consulta y me trae todos esos datos en
una sola conexion y en un solo recodset (o dataset). Cuando optimizo?,
bueno, no lo sabran hasta que hagan la prueba. Ojala se pueda hacer el
VFP.

Seria algo asi

create procedure usp_Multiplesconsultas
as
begin
select a,b,c,d from WWW;
select a,b,c,d from XXX;
select a,b,c,d from YYY;
select a,b,c,d from ZZZ;
end

y en tu codigo

abres conexion
defines recordset o dataset o datareader
cargas el primer resultado (select a,b,c,d from WWW)
lo procesas
NEXTRECORDSET
cargas el segundo resultado (select a,b,c,d from XXX)
lo procesas
NEXTRECORDSET
.
.
.
.cargas el ultimo resultado (select a,b,c,d from ZZZ;)
lo procesas
cierras conexion
eliminas objetos


ByteMad





"Jose Camacho Vaca" escribió
en el mensaje news:

Muchas gracias a todos por sus respuestas. Bueno, antes que nada, parece
que
de manera definitiva voy a tener que migrar a otra arquitectura.
Primero, el
volumen de datos no es tanto el problema, sino el trafico que hay en la
red,
normalmente un proceso implica lo siguiente:
Dame el No. de cliente.
Dame el detalle de la cuenta del cliente.
Dame los abonos del renglón 5 del detalle.
Dame los documentos del primer abono
y volvemos al primer paso.
Lo malo como pueden ver es que hay mucho trafico de ida y vuelta, no es
mucho con lo que se trafica, pero si muchas veces y eso multiplicado por
el
No. de equipos hace lenta la conexión.
Al parecer la solución va a ser ASP o algo por el estilo.
De todas formas cualquier sugerencia adicional va a ser bien recibida.
Gracias nuevamente y saludos.
José Camacho Vaca
Colima, MX


"Jose Camacho Vaca" wrote:

Una consulta, por razones de presupuesto tenemos conexion muy lentas a
nuestro servidor SQL, hasta 3 maquinas enlazadas sobre una conexion de
64kbps. Obviamente todo eso nos esta perjudicando en la velocidad de
nuestra
aplicación principal que es de tipo OnLine. Las características
generales
del sistema y de la infraestructura son las siguientes: servidor HP
Proliant
ML370 1Gb. RAM 3 DD SCSI de 40 Gb. (no estan en RAID),
SmallBussinessServer2003, SQL-Server2000, se conectan hasta 40
terminales
simultáneamente. Nuestra apliacion esta hecha en VFP8, usa
SQLPassThroug
bastante optimizado, todos los equipos terminales tienen WinXP-Pro con
256 de
memoria. Los que se conectan a la red local por medio de cable no
tienen
ningún problema, pero los que se conectan por medio de un enlace de
linea
dedicada de 64 Kbps, se vuelven muy lentos.
Cualquier sugerencia será bien recibida, mucha gracias.
Saludos.
José Camacho Vaca
Colima, MX

Hola Erik, lo que deberías de a hacer en vez de un procedimiento
almacenado, pienso yo, sería algo como esto:

m.lcSql = "SELECT a,b,c,d FROM WWW;" + ;
"SELECT a,b,c,d FROM XXX;" + ;
"SELECT a,b,c,d FROM YYY;" + ;
"SELECT a,b,c,d FROM ZZZ WHERE Campo1 = ?lnValor;" + ;
m.lnValor = 'MiValor'

m.lnHnd = SQLCONNECT()
SQLSETPROP(m.lhnd,"BatchMode" , .T.)
SQLEXECUTE(m.lnHnd, m.lcSQL, "Resul", aInfo)

P.D.- Por qué no dejan ya el hilo y se centran en SQL, sin ánimo de ofender.

Erik Martinez escribió:

yo programo en VFP y para ese caso yo mejor hago un solo procedimiento y
en el hago las uniones de las tablas que necesito para los respectivos
combos
y luego en el formulario antes de que el usuario seleccione un elemento de
la lista del combo filtro el resultado por los datos que corresponden a ese
combo, y es bien eficiente.

saludos.

"Fernando Fauche G." escribió en el mensaje
news:%

Insisto, no se como trabaja VFP, pero en mi codigo y procedimientos algo
que me agiliza TREMENDAMENTE las consultas es utilizar NEXTRECORDSET.


Si tengo que cargar cinco combos en un formulario, lo normal es realizar
cinco conexiones y que me devuelvan cinco objetos, pero con el
NEXTRECORDSET solo realizo una sola consulta y me trae todos esos datos en
una sola conexion y en un solo recodset (o dataset). Cuando optimizo?,
bueno, no lo sabran hasta que hagan la prueba. Ojala se pueda hacer el
VFP.

Seria algo asi

create procedure usp_Multiplesconsultas
as
begin
select a,b,c,d from WWW;
select a,b,c,d from XXX;
select a,b,c,d from YYY;
select a,b,c,d from ZZZ;
end

y en tu codigo

abres conexion
defines recordset o dataset o datareader
cargas el primer resultado (select a,b,c,d from WWW)
lo procesas
NEXTRECORDSET
cargas el segundo resultado (select a,b,c,d from XXX)
lo procesas
NEXTRECORDSET
.
.
.
.cargas el ultimo resultado (select a,b,c,d from ZZZ;)
lo procesas
cierras conexion
eliminas objetos


ByteMad





"Jose Camacho Vaca" escribió
en el mensaje news:

Muchas gracias a todos por sus respuestas. Bueno, antes que nada, parece
que
de manera definitiva voy a tener que migrar a otra arquitectura.
Primero, el
volumen de datos no es tanto el problema, sino el trafico que hay en la
red,
normalmente un proceso implica lo siguiente:
Dame el No. de cliente.
Dame el detalle de la cuenta del cliente.
Dame los abonos del renglón 5 del detalle.
Dame los documentos del primer abono
y volvemos al primer paso.
Lo malo como pueden ver es que hay mucho trafico de ida y vuelta, no es
mucho con lo que se trafica, pero si muchas veces y eso multiplicado por
el
No. de equipos hace lenta la conexión.
Al parecer la solución va a ser ASP o algo por el estilo.
De todas formas cualquier sugerencia adicional va a ser bien recibida.
Gracias nuevamente y saludos.
José Camacho Vaca
Colima, MX


"Jose Camacho Vaca" wrote:

Una consulta, por razones de presupuesto tenemos conexion muy lentas a
nuestro servidor SQL, hasta 3 maquinas enlazadas sobre una conexion de
64kbps. Obviamente todo eso nos esta perjudicando en la velocidad de
nuestra
aplicación principal que es de tipo OnLine. Las características
generales
del sistema y de la infraestructura son las siguientes: servidor HP
Proliant
ML370 1Gb. RAM 3 DD SCSI de 40 Gb. (no estan en RAID),
SmallBussinessServer2003, SQL-Server2000, se conectan hasta 40
terminales
simultáneamente. Nuestra apliacion esta hecha en VFP8, usa
SQLPassThroug
bastante optimizado, todos los equipos terminales tienen WinXP-Pro con
256 de
memoria. Los que se conectan a la red local por medio de cable no
tienen
ningún problema, pero los que se conectan por medio de un enlace de
linea
dedicada de 64 Kbps, se vuelven muy lentos.
Cualquier sugerencia será bien recibida, mucha gracias.
Saludos.
José Camacho Vaca
Colima, MX

Salu2 Rafael Cano
rcanop(arroba)yahoo.es
Jaén - España

Hola Fer, si si en vb6 hay una tecnica similar pero no es el modelo de
dataset de .net, esta bastante lejos de serlo, pero bueno este no es el foro
para hablar de ello :-)
Con respecto a la tecnica q usas en tus aplicaciones es ideal, hay solo q
traer lo necesario :-)


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"Fernando Fauche G." escribió en el mensaje
news:%

Lo que mencionas es una tecnica de programacion que se usa desde VB6...,
es el programador el que hace la diferencia, no el programa..., presumo
que en Net esta mas optimizado..., pero no es una solucion que sea de
el...

Desconosco como trabaja tu aplicacion, pero nosotros tenemos una realidad
similar y una de las primeras cosa que se tomaron en cuenta en el
desarrollo es "traer los datos estrictamente necesarios" y a traves de
"procedimientos almacenados optimizados" (no debe de existir el "select *
from ", sino el "select a,b,f,v from ", utilizacion de vistas en caso la
consulta sea demasiado compleja, la idea es cargar lo mas posible al motor
de base de datos en beneficio de traer la menor cantidad de informacion.

Otra cosa que se elimino es la tipica consulta con "un click en la
grilla", y asi vas optimizando poco a poco...

ByteMad


ByteMad


"Maxi" escribió en el mensaje
news:%239B7%

Hola, en .net cambia la cosa porque trabajas en un ambiente desconectado
con los Dataset


Salu2

Microsoft MVP SQL Server
Culminis Speaker

"principiante" escribió en el mensaje
news:%

No hay muchas posibilidades de mejorar siendo el cuello de botella una
red
lenta. Cuando la red es lenta, una solución basada en cliente grueso
(como es
el caso de VFP) es una mala solución.

Pero no porque sea VFP. Lo sería igual para cualquier Fat-client o para
cualquier aplicación windows típica de .NET.


Jose TH

Tienes razón, eso se puede hacer en VFP, un poco mas sencillo, en pocas
palabras solo mandas las instruccione SELECT al SQLserver y solito te regresa
varios RecordSet que aqui se llaman cursores. El problema es que eso sirve
para cuando sabes que le vas a pedir al server en los 4 SELECT que le mandas.
En mi caso, no lo se, hago el 1er. select, el operador escoge algo, en base
a esa selección se hace el 2º select y así sucesivamente. Espero haberme
explicado correctamente.
Te agradezco mucho tu ayuda de todas formas y si tienes alguna otra
sugerencia será bien recibida.
Saludos.
José Camacho Vaca
Colima, MX


"Fernando Fauche G." wrote:

Insisto, no se como trabaja VFP, pero en mi codigo y procedimientos algo que
me agiliza TREMENDAMENTE las consultas es utilizar NEXTRECORDSET.


Si tengo que cargar cinco combos en un formulario, lo normal es realizar
cinco conexiones y que me devuelvan cinco objetos, pero con el NEXTRECORDSET
solo realizo una sola consulta y me trae todos esos datos en una sola
conexion y en un solo recodset (o dataset). Cuando optimizo?, bueno, no lo
sabran hasta que hagan la prueba. Ojala se pueda hacer el VFP.

Seria algo asi

create procedure usp_Multiplesconsultas
as
begin
select a,b,c,d from WWW;
select a,b,c,d from XXX;
select a,b,c,d from YYY;
select a,b,c,d from ZZZ;
end

y en tu codigo

abres conexion
defines recordset o dataset o datareader
cargas el primer resultado (select a,b,c,d from WWW)
lo procesas
NEXTRECORDSET
cargas el segundo resultado (select a,b,c,d from XXX)
lo procesas
NEXTRECORDSET
..
..
..
..cargas el ultimo resultado (select a,b,c,d from ZZZ;)
lo procesas
cierras conexion
eliminas objetos


ByteMad





"Jose Camacho Vaca" escribió en
el mensaje news:
> Muchas gracias a todos por sus respuestas. Bueno, antes que nada, parece
> que
> de manera definitiva voy a tener que migrar a otra arquitectura. Primero,
> el
> volumen de datos no es tanto el problema, sino el trafico que hay en la
> red,
> normalmente un proceso implica lo siguiente:
> Dame el No. de cliente.
> Dame el detalle de la cuenta del cliente.
> Dame los abonos del renglón 5 del detalle.
> Dame los documentos del primer abono
> y volvemos al primer paso.
> Lo malo como pueden ver es que hay mucho trafico de ida y vuelta, no es
> mucho con lo que se trafica, pero si muchas veces y eso multiplicado por
> el
> No. de equipos hace lenta la conexión.
> Al parecer la solución va a ser ASP o algo por el estilo.
> De todas formas cualquier sugerencia adicional va a ser bien recibida.
> Gracias nuevamente y saludos.
> José Camacho Vaca
> Colima, MX
>
>
> "Jose Camacho Vaca" wrote:
>
>> Una consulta, por razones de presupuesto tenemos conexion muy lentas a
>> nuestro servidor SQL, hasta 3 maquinas enlazadas sobre una conexion de
>> 64kbps. Obviamente todo eso nos esta perjudicando en la velocidad de
>> nuestra
>> aplicación principal que es de tipo OnLine. Las características
>> generales
>> del sistema y de la infraestructura son las siguientes: servidor HP
>> Proliant
>> ML370 1Gb. RAM 3 DD SCSI de 40 Gb. (no estan en RAID),
>> SmallBussinessServer2003, SQL-Server2000, se conectan hasta 40 terminales
>> simultáneamente. Nuestra apliacion esta hecha en VFP8, usa SQLPassThroug
>> bastante optimizado, todos los equipos terminales tienen WinXP-Pro con
>> 256 de
>> memoria. Los que se conectan a la red local por medio de cable no tienen
>> ningún problema, pero los que se conectan por medio de un enlace de linea
>> dedicada de 64 Kbps, se vuelven muy lentos.
>> Cualquier sugerencia será bien recibida, mucha gracias.
>> Saludos.
>> José Camacho Vaca
>> Colima, MX