Ayuda con aplicaciones en red....

[lgsiemen]

Que tal, es un gusto unirme a esta gran comunidad.

 

Verán, hace un par de años empece a trabajar con foxpro, en una empresa me contrataron para ver el tema de 2 sistemitas, empee a trabajar con tablas libres, usando codigo sencillo con store, replaces, busquedas en grid, locates, etc... el programa funciona de lo mas lindo en una pc, hace un tiempo me pidieron que el mismo programa este en otra pc debido a que se incrementeo el llenado de datos.......

 

el mismo programita lo puse en la otra pc (no estan usando los mismos archivos, sino cada uno con sus propios formularios, informes, etc) solo la data esta en una unidad de red, ahi empezaron mis problemas....

 

1.- en primera instancia cambie los delete-pack por delete y usando el "set delete on"

2.- cree mi dbc, empece a añadir indices y usar otros comandos por ejemplo seek en vez del locate

3.- cuando solo una persona esta llenando datos (ya sea en la pc con los datos o en la otra - PERO SOLO UNA) funciona de maravilla... basta que la otra pc use el programa y use la misma tabla para que el sistema se torne muy lento.

 

Ejemplo:

Tengo un formulario con un grid y un campo de texto en el que introducen un codigo, se hace un filtro sobre una tabla y lo muestra en el grid.

El otro usuario en su propio programa hace una operaion similar con otro codigo para filtrar, se demora demasiado.

 

La verdad estoy algo desesperado, las pcs son nuevas, la red trabaja de 1gb.

Estoy seguro que estoy haciendo las cosas mal.

 

Tambien quisiera sabr cual seria la forma correcta de actualizar un registro

De ingresar un nuevo registro

De hacer un filtro y mostrarlo en un grid

De actualizar ese filtro...

 

Como un dato adicional, hice una prueba..... Ejecuto la aplicacion en una pc, me voy a la otra y no abro la aplicacion, sino desde el foxpro le doy un use a la tabla y aplico un set filter y demora mucho, le doy un browse y demora.... hago otro filtro y sigue demorando.....

 

Espero puedan darme una orientacion. Gracias

[Carlos Miguel FARIAS]

Fijate si este link te puede dar una solución

http://translate.googleusercontent.com/translate_c?anno=2&depth=1&hl=es&rurl=translate.google.com.ar&sl=en&tl=es&twu=1&u=http://support.microsoft.com/kb/296264/en-us&usg=ALkJrhghdfJGp8avodrTJyEP2ISUtAfrfA

He leido en alguna parte que no recuerdo, que con algunas versiones de windows server, hay configurado un parametro del SO que cuando varios usuarios en la red quieren acceder al mismo archivo, se produce un disminución de desempeño exponencial.

O sea, no es un problema de VFP si no de configuración del SO
Saludos: Miguel, La Pampa (RA)

--
 
 
 

[Alejandro Isla]

¿De que tamaño de bases estamos hablando? recuerda que cuando usar el servidor como "servidor de archivos" te tiene que mover toda la tabla al terminal para hacer las consultas, filtros, etc.

Muchas veces se soluciona transformando el servidor en un servidor sql (servidor de base de datos), por lo que solo te traslada por la red los registro seleccionados.

Claro que siempre está el tema de optimizar las consultas e indices para que aproveche la tecnología rushmore que tiene el fox.

¿Tu servidor que es, linux, win, etc? no probaste meter algún programita en el servidor para visualiza el tráfico de la red.

Saludos

[lgsiemen]

Gracias por tu respuesta Miguel.

todas las pcs tienen windows xp, tambien ocurre eso de la disminucion exponencial?

Saludos

 

Te comento que el sistema operativo con que trabajo es

[Walter R. Ojeda Valiente]

A primera vista tienes varios problemas que afectan al rendimiento:
1. Estás usando LOCATE, no deberías hacerlo, indexa las tablas y usa SEEK en su lugar, siempre. O mejor aún, usa SELECT SQL
2. Estás usando SET FILTER, no deberías hacerlo, recupera en un cursor los datos que quieres mostrar usando SELECT SQL
3. Tus formularios deben tener la propiedad DataSession en 2 - Private Data Session
4. No dejes tus tablas abiertas, el procedimiento correcto es el siguiente:
    a. Abrir la tabla
    b. Recuperar los datos deseados en un cursor
    c. Cerrar la tabla
    d. Usar el cursor para navegar la tabla (primero, anterior, siguiente, último) y cuando se debe agregar/borrar/modificar datos solamente en ese momento abrir la tabla, actualizarla, volver a cerrarla
5. Verifica también la normalización de tus tablas, las tablas no normalizadas requieren de un mayor tráfico en la red y por lo tanto son más lentas que las normalizadas
6. ¿Cuántos índices tienes? ¿Son todos imprescindibles? Tener índices que no se usan o que se usan poquísimo solamente sirve para enlentecer todas las operaciones
7. Adicionalmente, si quieres que tus aplicaciones "vuelen" en la red y que sean mucho más seguras, olvídate de las tablas .DBF y migra a SQL. En particular te aconsejo Firebird SQL, es rapidísimo, muy poderoso, muy fácil de aprender a usar y sobre todo, gratis, siempre gratis.

Saludos.

Walter.

"Si puedes razonar con gente religiosa, no son gente religiosa". Dr. House

---

Date: Sun, 11 Nov 2012 21:17:00 -0800
From: lgsi...@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] Ayuda con aplicaciones en red....

--
 
 
 

[Fox Learner *]

Igsiemen

Quizás le sirva revisar este enlace de este tema del foro:

Como se entiende el "IF Rock()"

https://groups.google.com/forum/#!topic/publicesvfoxpro/SqGtvh8W_io

Saludos!

[Fox Learner *]

Walter, 

El proceso que indicas sería el recomendable si se usa Firebird?...

(Se entiende que ya se abrió la conexión..)

a. Abrir la tabla (Aquí entiendo que se haría una consulta con SQLEXEC().

b. Recuperar los datos deseados en un cursor

c. Cerrar la tabla (Aquí supongo que se cerraría la conexión)
d. Usar el cursor para navegar la tabla (primero, anterior, siguiente, último) y cuando se debe agregar/borrar/modificar datos solamente en ese momento abrir la tabla(antes la conexión, supongo), actualizarla, volver a cerrarla (y otra vez cerrar la conexión).

Donde quisiera saber si es correcto hacer esto es en los updates..

¿Cuál es la forma recomendada para "volcar" todos los datos modificados en el cursor hacia el SGBD?..

Si me pides que abra un nuevo tema, lo haré con gusto..

Saludos!

[lgsiemen]

Hola, gracias por tu comentario, estoy revisando con detenimiento cada una de sus apreciaciones...
habia visto el comando pero no sabia que tenia que ponerlo cada vez que necesitaba actualizar los registros.

Muchas gracias

[Walter R. Ojeda Valiente]

No, lo que le había recomendado es para tablas .DBF

En cuanto a Firebird, si tu red es confiable puedes conectarte a la BD al iniciar tu aplicación y desconectarte al finalizar la aplicación. Si tu red no es confiable (por ejemplo, con un notebook viajando y con la conexión cortándose a cada rato) es preferible conectarte, ejecutar el comando, desconectarte.

Saludos.

Walter.

"Si puedes razonar con gente religiosa, no son gente religiosa". Dr. House

---

Date: Mon, 12 Nov 2012 13:41:10 -0600
Subject: Re: [vfp] Ayuda con aplicaciones en red....
From: thenewin...@gmail.com
To: publice...@googlegroups.com

--
 
 
 

[Ernesto Leiva]

Esto me paso a mi tambien... la solucion es NO USAR FILTER o filtros de ninguna clase.

Resolvelo a tu manera son los SEEK, usando archivos indices.

[Alejandro Isla]

No creo que andas conectandose y desconectando de la DB sea lo adecuado; ya que eso implica un tráfico que se puede evitar y en caso de análisis del log del server, pude resultar extraño el "prende / apaga" constante.

Si queres hacer el código más robusto, podes reemmplazar la comando sqlexec() por una rutina propia, donde antes o despues de la sentencia sqlexec() controlas la existencia de la conexión / análisis de error

algo como
lparameters nHandle, cSentencia, cBase
si !Conexiondb
     volver a conectar
finsi
=sqlexec(nHandle,cSentencia,cBase)


o
lparameters nHandle, cSentencia, cBase
try
     =sqlexec(nHandle,cSentencia,cBase)
catch
     analizar error, reconectar y volver a ejecutar sqlexec()
endtry

[lgsiemen]

La data son solo 120Mb

Me han sugerido sql, tengo que aprenderlo, pero antes no puedo avanzar si no soluciono este problema, debo identificar ants cuales sOn mis errores.... ademas que tan solo son 3 usuarios Y 120 mb. a lo largo de 3 años!!! 
estoy seugro que tengo algun otro tipo de problema, por comemntarios veo que otros usuarios tiene un sistema en
foxpro con n usuarios, mucho mas pesados y trabaja rapido... yo no deberia tener problemas...

He verificado el rushmore al 100%, los informes son rapidisimos pues solo hago las consultas y leo la informacion en
el archivo de informe.

Mi gran problema y duda lo veo por estos 2 puntos.

1. Una computadora usando el programa, la otra no usa el programa pero accedo desde el foxpro a la data, en

especifico a la tabla mas grande (105mb) y hacer el filtro demora, y si le doy un browse uffff se pone en blanco y

tarda mucho en mostrar los datos. Puee ser problema del foxpro?  Estoy usando vfp 9 sp1, antes tuve el 6.0 e igual...


2. El programa. En especial en un modulo, se trata de un formset con 2 formularios.

* Se visualiza solo 1 formularios, en el load carga las tablas, se presenta demora cuando 2 o 3 usuarios estan usando

el programa)

* En dicho formulario tengo 1 grid, alguna scajas de texto y algunos botones, una de las cajas de texto tiene el

valid:

  -> Selec LaTabla   (la de 105 mb)
  -> Set order to ElIndice 
  -> Set filter to criterio1 and criterio2 and criterio3
  -> Seek MiValor
  -> Store datos a variales y mostrarlos en las cajas de texto y grid

  He puesto puntos para ver donde demora mas y en este caso ha sido en el seek

* En el segundo formulario tengo tambien un grid y cajas de texto pero a diferencia del anterior aqui lleno datos a
una tabla con estructura identica a la tabla principal, cuando doy clic en el el boton aceptar hace un append y
tambien demora...

estoy seguo que tengo mucho por corregir en programacion... pero tambien me genera una duda el punto 1, sin necesidad

de abrir el programa, accedo a la tabla mediante foxpro y los set filter a veces me van rapido peor en el brow se
demora... tambien no se si es correcto, hago un filtro y utilizo: sum total to variable...... y esto me demora al
igual que el calculate(max)...

Gracias Alejandro

[leonardo trujillo]

por lo visto no estás trabajando con cursores
¿por qué no cargas en un cursor los datos que necesitás y sobre el cursor, en memoria y no en la tabla, hacés el resto?

--
 
 
 

[lgsiemen]

Hola Caterva, gracias por escribir.

Para los modulos que tengo de puros informes si utilizo cursores y me va rapidisimo.... el es que en este formulario el filtro que hago es porque es un asiento contable y tengo que hacer el filtro de varios registros por ejemplo para un asiento Nº1 hay 4 registros, para un asiento Nº2 hay 6 registros

El campo de texto introduces el numero del asiento, se realiza el filtro (por asiento y periodo) y se muestra en el grid.
un boton te da la posibilidad de modificar y creo que esta mal, pues al hacer clic en modificar habilita el grid para modificar los datos que directamente se estan haciendo en la tabla, o sea el grid esta amarrado a la tabla  mas por la modificacion....

Me gustaria saber como hacer para llenar el grid con un cursor, que propiedades debo asignar al grid y que como iria "filtrando o actualizando" el grid segun la consutla que hago (recordar que el contenido del grid cambia segun el numero de asiento que se le indique) y por otra lado lo mas importante.... ¿como haria para de ese cursor actualizar los datos de la tabla?.

Ayer estuve metiendo en el codigo puntos de interrupcion para identificar donde demoraba, mejoro el tiempo pero me lleve la gran sorpresa que despues de cargar todas las tablas en el load, demoraba en "aparecer el formulario", coloque mas puntos ahora en el init y tambien los pasaba rapido.... solo por probar borre el grid del formulario e increiblemente los filtros, seek, locate, etc  funcionaron veloz!!!!  ----> Ojo que en todo momento estaban 3 usuarios conectados a la data usando el mismo formulario, peor el mio sin el grid y estaba rapido...

Nuevamente gracias por tu ayuda.

[FidelJ]

Sigue las recomendaciones de Walter Ojeda Valiente. No utilices SET FILTER sobre tablas en servidor. Es terriblemente lento. Aún cuando tengas un solo equipo trabajando. 

Utiliza SELECT SQL para obtener un conjunto de datos en un cursor READWRITE. A este lo puedes indexar como te convenga y utiliza las funciones Seek() ó Indexseek() en lugar del comando SEEK con If Found(). En un cursor de pocos registros (digamos 1000, por ejemplo), LOCATE funciona también muy rápido.

También puedes usar SET FILTER sobre el cursor, pero muy probablemente no valga la pena.

Aunque no es recomendable utilizar este tipo de procedimientos porque son para tablas nativas exclusivamente, para el caso de los registros de cuerpo de asiento, si tienes un índice sobre el número de asiento, puedes utilizar un cursor gemelo. Esto no tiene la funcionalidad de SELECT SQL, pero para casos sencillos puede trabajar más rápido.

* Supuestos;

* Tabla de registro de asientos: REGASI.DBF

* Campos (NUMASI I,FECHA D,CODCTA C(6),DEBE N(12,2),HABER N(12,2) )

* Indexado: INDEX ON NUMASI TAG rgaNumasi

Rutina

nAsiento=(Número de asiento buscado)

if ShowAsiento(nAsiento)

select miAsiento

browse

endif

Procedure ShowAsiento(xnNumAsi)

*******************************

if empty(xnNUmasi)

return .f.

endif

if !indexseek(xnNumasi,.f.,"REGASI","RGANUMASI")

mESSAGEBOX("No hay cuerpo de asiento")

return .f.

endif

select REGASI

aFields(gastruct)

create cursor miAsiento from ARRAY gastruct

select REGASI

SET ORDER TO RGANUMASI

indexseek(xnNumasi,.t.,"REGASI","RGANUMASI")

do while numasi=xnNumasi

scatter MEMVAR

INSERT INTO MIASIENTO FROM MEMVAR

SKIP

IF EOF()

EXIT

ENDIF

ENDDO

select miAsiento

GO TOP

return .t.

ENDPROC

El lunes, 12 de noviembre de 2012 02:17:00 UTC-3, lgsiemen escribió:

[Carlos Miguel FARIAS]

Estás seguro que no es un problema del compartir archivos a nivel de S.O. y nada que ver con que sea VFP. Proba de abrir un archivo de procesador de texto. Primero en forma individual, y luego en forma compartida y controla los desempeños.

Saludos: Miguel, La Pampa (RA)

--
 
 
 

[Fox Learner]

Como dijo Jack "el destripador"...: Vamos por partes jeje

Igsiemen,

Veo que tiene una serie de dudas.

1. Me gustaria saber como hacer para llenar el grid con un cursor

Revise la ayuda del comando Select. Algo como:

Sele * from Mitabla Where Campo X like '%Cadena a buscar%' INTO CURSOR NombredemiCursor

Sele  NombredemiCursor

Brow

2. que propiedades debo asignar al grid

Muchas, pero de las mas trascendentes, Readonly, debe estar en "falso". 

3. y que como iria "filtrando o actualizando" el grid segun la consutla que hago (recordar que el contenido del grid cambia segun el numero de asiento que se le indique) 

Para evitar que el grid se ponga en blanco:

*** desenlazar  el cursor del Grid.
thisform.grid1.recordSource = ""

4. y por otra lado lo mas importante.... ¿como haria para de ese cursor actualizar los datos de la tabla?.

Se puede tomar como referencia los datos no repetidos contenidos en el campo que funciona como clave primaria, para hacer una consulta de actualización o los replace's.

También hay un tema bonito sobre el sistema de buffering para hacer un "cursor actualizable", pero no me salió uuuuuu

Bueno, es lo que lo puedo comentar..

Saludos!

[Fox Learner]

Am.. me equivoqué..

2. que propiedades debo asignar al grid

Muchas, pero de las mas trascendentes, Readonly, debe estar en "verdadero". 

Saludos!

[Carlos Miguel FARIAS]

Jack el destripador no descuartizaba, solo "destripaba".
Alguien que hizo bien el tema de ir por partes fue Gonzani, aca en la Pampa
(Busca en google: Gonzani La Pampa Argentina, vas a ver articulos en cantidad, hasta se hizo una película).
Bueno el tema es que este señor descuartizo a su mujer, y según parece, lo escondio en la heladera.
Conclusión de dia viernes: La heladera era chica.

Saludos: Miguel, La Pampa (RA)

--
 
 
 

[lgsiemen]

Hola Walter, al igual que los demas miembros, les estoy muy agradecido por tomarse un tiempo para ayudarme.

He encontrado un grave error en mi programa que esta causando la lentitud, de todas formas ya cambie los locates por seek, tambien estoy usando el procedimiento que m eindicas para abrir y carrar tablas y tomare en cuenta lo del firebird; pero antes quiero dar solucion a este problema...

Sabes, encontre que el formulario demoraba en cargar por el grid, y todos los filtros que hace desde el campo de texto, se demora por mostrar los datos en el grid.

Borre el grid y los filtros los realiza bien rapido, pero de todas maneras pienso dejar los set filt porque todos me lo han recomendado... probe llenar el grid con una sentencia sql y me va rapido, el problema es tener el grid con el recordsource la tabla de 105mb.... 

por ahora la sigo teniendo igual ya que tengo un boton modificar que habilita el grid para modificar los datos del filtro, de otra forma usando el cursor, probe en readwrite pero no se actualiza en la tabla.... alguna solucion?

Gracias

[Walter R. Ojeda Valiente]

¿Estás mostrando en tu grid una tabla que tiene 105 megabytes?

Ese es un grandísimo error de concepto, jamás de los jamases un usuario recorrerá un grid tan grande, imposible.

Lo que debes hacer es acotar lo que muestras en tu grid. Por ejemplo podrías hacer un SELECT para obtener los primeros 100 registros de tu tabla, luego si el usuario hace click sobre el botón "Siguiente" borras esos 100 registros y obtienes 100 registros más y se los muestras en el grid. Y así sucesivamente.

Obtener y mostrar 100 registros es rapidísimo, los usuarios podrán ver lo que desean y todos contentos y felices.

Saludos.

Walter.

"Si puedes razonar con gente religiosa, no son gente religiosa". Dr. House

---

Date: Thu, 15 Nov 2012 05:15:04 -0800
From: lgsi...@gmail.com
To: publice...@googlegroups.com
Subject: Re: [vfp] Ayuda con aplicaciones en red....

--
 
 
 

[Hugo Carlos Aguilar Zapata]

Sobre:

por ahora la sigo teniendo igual ya que tengo un boton modificar que habilita el grid para modificar los datos del filtro, de otra forma usando el cursor, probe en readwrite pero no se actualiza en la tabla.... alguna solucion

Si el cursor es ReadWrite los cambios se hacen pero solo en esa tabla temporal, tendria que trasladar esos cambios a los registros de la tabla real.

Esto puede hacerse por ejemplo con la acción de un botón o al momento de recorrer y modifcar cada campo o registro del cursor utilizando REPLACE o UPDATE SQL en la tabla original

 

Saludos

 

 

--
 
 
 

[lgsiemen]

Si, desde un principio del formulario en el grid no muestra nada, luego va mostrando pero segun los filtros (3 a 10 registros maximo), NUNCA muestra los 105mb, pero de todas maneras lo tiene como Source y ese es el problema.

Ir cargandolo de una sentencia sql es rapido pero para actualizar estuve buscando informacion y veo que asi le ponga readwrite no guardara porque cursor es cursor y no la tabla, cambio que haga no se afectara la tabla.... entonces   encontre sugerencias como: hacer un barrido con scan en el cursor y actualizar los datos en la tabla princiapl, en verdad es buena idea sin embargo tambien otros usuarios dicen que eso es una salida y seria mejor usar vistas que se actualizaran en la tabla principal.... me gustaria tu opinion sobre eso y si es verdad, como lo haria.

Gracias nuevamente

[lgsiemen]

Gracias WoodFan,
efectivamente he comprobado que ser readwrite no quiere decir que se actualice en la tabla principal, tendria que hacer una operacion de scan en el cursor y actualizar en la tabla principal, tal como lo indicas..... de no encontrar otra solucion, utilizare esta forma....

Sabes algo sobre vistas y tableupdate? puedo generar una vista desde un boton command y mostrarlo en el grid? (esto reemplazaria a mis set filter y seek)

Gracias.

[Guillermo MDQ]

Las vistas son una buena alternativa, ya que son actualizables y se pueden filtrar.
Puedes usar el asistente para crear vistas del vfp y veras que son sencillas de utilizar.
Y tambien te recomiendo que le des una leida a la ayuda del vfp-

Saludos
Guillermo

[Walter R. Ojeda Valiente]

¿Cuál es tu idea, que apenas el usuario cambie algo en la grilla también se cambie en la tabla original?

Lo normal es que haya un botón de "Grabar" para que al hacer click sobre él los cambios se graben en la tabla. La ventaja de hacerlo así es que mejoras las validaciones que afectan a varios registros, no solamente al que acaba de cambiar el usuario.

En cuanto a tu grilla, no deberías tener como source a tu tabla de 105 megabytes, sino al cursor que tiene los datos que se les muestran a los usuarios (esos 3 a 10 registros como máximo).

La lógica sería algo así:
ThisForm.Grid1.RecordSource = MiCursorGrid
SELECT MisCampos FROM MiTabla WHERE MiCondicion INTO MiCursorTabla
select MiCursorGrid
ZAP
APPEND FROM MiCursorTabla
Locate
ThisForm.Grid1.Refresh()

Pruébalo, verás que así siempre es rapidísimo.

Saludos.

Walter.

"Si puedes razonar con gente religiosa, no son gente religiosa". Dr. House

---

Date: Thu, 15 Nov 2012 05:41:47 -0800

--
 
 
 

[Antonio.xt]

Igsiemen, tienes el grid enlazado a una tabla de 105 Mb?

Como te indica Walter, eso es un error de concepto, de hecho no deberias tener una tabla enlazada a un grid, aun que si se puede y el Fox te lo permite, pero es una mala practica; es mejor tener enlazado un Query o cursor. Y no se donde te han recomendado usar los SET FILTER ya que aqui siempre sugieren el uso de sentencias SELECT en vez del SET FILTER. Si te lo han recomendado en la escuela, esta bien, ya cuando avances tu mismo te daras cuenta al usar los 2 metodos. Pero te comento que aqui muchos ya han pasado por eso y ya han probado usar los filtros y los SELECT.

Si lo que quieres es que el usuario pueda modificar los datos de la tabla directamente en el Grid, pues ese es otro error de concepto, ya que la dejas completamente abierta y sin validaciones, y pudieran cambiar datos de forma equivocada. Si ese es el objetivo de la terea que te encargaron no hay problema, solo que sera muy lento. Pero si quiere que realmente funcione bien debes cambiar la logica que estas usando.

Podrias hacer esto:

Por medio de los fitros llenas el Grid con un cursor generado obviamente de una sentencia SELECT.

El Grid debe tener la propiedad ReadOnly en .T. para que no cambien los datos, o el cursor generado que no sea READWRITE

Si quieres cambiar datos de un registro, se selecciona el registro del Grid con Enter o Click y que se abra un formulario que muestre los datos de ese registro

Ese formulario debe tener habilitados los objetos para cambiar datos y debe tener los botones "Aceptar" y "Cancelar"

Si seleccionas "Aceptar"

Busca ese registro ahora si en la tabla de 105 Mb, ya sea con SEEK, LOCATE, o lo que quieras, pero SEEK es mejor (debes tener activo un indice para usar SEEK)

Actualizas los datos en la tabla con REPLACE o UPDATE

 Y listo !!

No se si eso sea lo que necesites, pero ahi te das una idea.

Saludos...

Charles A. Moreno

[Hugo Carlos Aguilar Zapata]

nop siempre he trabajado mejor con Cursores y actualizaciones a la tabla con sentencias SQL, dejé de usar set filter por SELECT SQL .. WHERE ..., lo mismo para buscar registros con SEEK, claro que en algun momento los puedes utilizar, pero de esta manera te vas adaptando a una arquitectura C/S donde puedes migrar tu almacenamieto a servidores de BD como MySQL, MSSQL Sever, Firebird y demás, que  te dan seguridad, desempeño y gran capacidad.

 

Espero y alguien pueda apoyarte sobre el uso de vistas para que hagas un comparativo y tomes la mejor elección

 

Saludos

Hugo Aguilar

--
 
 
 

[Miguel Canchas]

Usa cursoradapter

 

* This script handles the ADO Connection and uses a CursorAdapter object

* to retrieve data to a cursor.

 

PUBLIC oCA as CursorAdapter

LOCAL oConn as ADODB.Connection

LOCAL oRS as ADODB.Recordset

LOCAL oException AS Exception

LOCAL cConnString

 

* Handle connections - insert connection code

cConnString = [Provider=SQLOLEDB.1;Data Source=XIMESRV2;Initial Catalog=Ximesa;User ID=mcanchas;Password=MIGCAN10]

 

TRY

    oConn  = createobject('ADODB.Connection')

 

    * Ensure that you handle userid and password if not

    * specified in connection string.

    *   ex. oConn.Open(cConnString, userid, password)

    oConn.Open(cConnString)

 

    oRS = CREATEOBJECT("ADODB.Recordset")

    oRS.DataSource.CursorLocation = 3   &&adUseClient

    oRS.DataSource.LockType = 3   &&adLockOptimistic

    oRS.ActiveConnection = oConn

 

    oCA=CREATEOBJECT("CursorAdapter")

    oCA.DataSourceType = "ADO"

    oCA.DataSource = oRS

    oCA.MapBinary = .T.

    oCA.MapVarchar = .T.

 

    oCA.Alias = "mitabla"

    oCA.SelectCmd = "SELECT * FROM mitabla WHERE cia = '01' and dni = '3243243433'"

   

    IF !oCA.CursorFill()

        * Replace with error code here

        LOCAL laError

        DIMENSION laError[1]

        AERROR(laError)

        MESSAGEBOX(laError[2])

    ELSE

        * Replace with user code here. Code below allows for

        * you to edit and send updates to the backend.

        LOCAL laFlds,lcStr,lnFldCount,i

        DIMENSION laFlds[1]

        lnFldCount=AFIELDS(laFlds)

        lcStr=""

        FOR i = 1 TO lnFldCount

                lcStr = lcStr + laFlds[m.i,1] +  ","

        ENDFOR

        oCA.UpdatableFieldList = lcStr

        BROWSE NORMAL NOWAIT

    ENDIF

 

CATCH TO oException

    * Replace with exception handling code here

    MESSAGEBOX(oException.Message)

 

ENDTRY

 

* Add user code here.

* Note: cursors created by CursorAdapter object are closed when object is released.

--
 
 
 

[leonardo trujillo]

igsiemen, ayer quise pasar por acá un form de ejemplo y como no me lo permitió te lo mandé por mail ¿te llegó?

Además ¿alguien sabe por qué no se pueden adjuntar .rar con forms comprimidos?

--
 
 
 

[Víctor Hugo Espínola Domínguez]

Hola Leonardo

Mira este enlace: http://support.google.com/mail/bin/answer.py?hl=es&answer=6590

Es muy fácil engañarle, simplemente cambia la extensión rar a cualquier otra ;-)

Saludos.

Víctor.

--
 
 
 

[leonardo trujillo]

van de nuevo
es un .zip y adentro van dos .rar

El 14 de noviembre de 2012 12:35, leonardo trujillo <trujillo...@gmail.com> escribió:

recordsource mitabla
recordsourcetype 1-alias

te mando un form que puedes analizarlo para ver cómo trabajo y la tabla

--
 
 
 

[leonardo trujillo]

impeca
saludos

El 22 de noviembre de 2012 17:47, lgsiemen <lgsi...@gmail.com> escribió:

Hola caterva, gracias por tu ayuda, si me llegaron los archivos a mi correo, perdon por la demora, estuve con mucha carga de trabajo, recien me libero un poco....

Muchas gracias nuevamente, el formulario y el codigo esta muy entendible. Saludos.

--