Foros Club Delphi - Paradox en Red

Foros Club Delphi (https://www.clubdelphi.com/foros/index.php)

- Conexión con bases de datos (https://www.clubdelphi.com/foros/forumdisplay.php?f=2)

- - Paradox en Red (https://www.clubdelphi.com/foros/showthread.php?t=16574)

Gente,

Tengo un problema que necesito resolver. Resulta que estoy haciendo una aplicación con multiples tablas y necesito que estas puedan ser accedidas tanto local como en Red.

Ya lei el articulo de "paradox en red" y me ayudo mucho pero mi duda esta en como manejar las inserciones, pongo autonumerico? o busco cual es el primero sin usar?. Que pasa si dos usuarios quieren agregar al mismo tiempo a la tabla? que valor les asigno y como evito que o el indice cresca muy rapido o se quieran ingresar dos con el mismo valor
Estoy trabajando en Delphi6+Paradox7+DBE.

Agradesco sus comentarios y sugerencias

Yo en Paradox utilizo una tabla auxiliar en la guardo el último número utilizado, para dar un alta:
1. lo pongo en edición le sumo 1
2. Grabo el registro y ya está
3. el próximo que intente grabar ya sabe cual es el último número.

Esta operación solamente la hago cuando el usuario pulsa el botón de agregar, de momento le asigno un número por encima del que nos encontramos, suelo utilizar el nº del usuario que hace la factura y lo multiplico por 20 por ejemplo, de esta manera los números provisionales nunca coincidirán, sino se graba pues nada cancelamos y como el número no se modificó se queda todo como estaba.

Por otra parte si se accede de manera concurrente a las tablas todos incluso el propio equipo que contiene las tablas debe de acceder por la red no de forma local.

Un Saludo.

Primero gracias por tu respuesta, ;)
Pero... :rolleyes:
Digamos que el hecho de almacenar en una tabla auxiliar los valores de los indices no es muy elegante que digamos. Además continua con el mismo problema porque que pasa si yo le quiero asignar el siguiente a dos registros al mismo tiempo?
Otro detalle por el cual tu solucion no me sirve es que yo necesito el "ID" real desde un principio porque creo en tablas secundarias detalles sobre el registro de la tabla principal y si este le pusiera un indice "temporario" tendria que cambiarselo despues a todas las otras por el real.

Gracias por tu ayuda igualmente, pero tenes otra idea??? :confused:

Cita:

Empezado por Mariana

Digamos que el hecho de almacenar en una tabla auxiliar los valores de los indices no es muy elegante que digamos.

No sé qué entiendes por elegante pero ésta es una técnica muy común y efectiva.

Cita:

Empezado por Mariana

Además continua con el mismo problema porque que pasa si yo le quiero asignar el siguiente a dos registros al mismo tiempo?

Pon un bloqueo de lectura en la tabla auxiliar para que otras aplicaciones no puedan leer el valor mientras una lo está actualizando.

Cita:

Empezado por Mariana

Otro detalle por el cual tu solucion no me sirve es que yo necesito el "ID" real desde un principio porque creo en tablas secundarias detalles sobre el registro de la tabla principal y si este le pusiera un indice "temporario" tendria que cambiarselo despues a todas las otras por el real.

Me parece que el valor temporal al que se refiere Marcos es porque en cuestión de facturas normalmente no se permiten huecos, cosa que sucedería si desde un principio pones el valor real. Esto es así porque no puedes mantener el bloqueo mucho tiempo o crearás un cuello de botella en tu sistema.

Si el valor lo necesitas únicamente para relacionar tablas entonces puedes colocar el valor real desde un principio. Aunque de ser así puedes quedarte con campos autoinc sin más. El motor del BDE se encarga de no asignar el mismo a dos aplicaciones.

He visto varios comentarios contra el uso de este tipo de campos pero a mi no me han dado ningún problema.

// Saludos

Lo que quieres hacer es bastante sencillo. Supongamos que tienes un DataModule con tus DataSet's (si no lo tienes, deberías), bien, te declaras una variable privada de tipo integer, supongamos que se llama ContError. Bien, luego te programas una rutina de este estilo:

Código:

procedure TDataModule1.EditErrore(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction);

begin

  if ContError > 3 then

  begin

    ShowMessage('El registro no se puede editar, intentelo más tarde');

    Action := daFail;

    ContError := 0;

  end else

  begin

    Inc(ContError);

    Sleep(2000);

    Action := daRetry;

  end;

end;

Bien, la rutina hace lo siguiente. Si el contador de intentos es mayor que 3 (por ejemplo), saca un mensajote avisando, reinicia el contador y cancela. Si es menor, aumenta el contador, "duerme" durante 2 segundos (con la esperanza que el registro deje de estar bloqueado) e intenta de nuevo la acción.

Ahora solamente te falta asignar esta rutina al OnEditError de todos los datasets que quieras controlar.
Evidentemente puedes sofisticar el procedimiento, por ejemplo, con un form que avise al usuario de que se está intentando acceder al registro.

Me parece que no hablamos de lo mismo o al menos yo no he entendido lo que tu dices.

Yo no hablo de índices sino de un número único que debe de identificar a una factura y no se debe repetir ni dejar huecos.

Situación con tablas Paradox, para otro tipo de tablas hay otras soluciones, como generadores....

Estamos trabajando directamente con la tabla facturas en red.
Último número de factura el 800
El usuario A, inicia la grabación de una factura lógicamente por el método que sea es la 801, graba 5 líneas y queda esperando a que el vendedor por teléfono le concrete el resto de la venta.

El usuario B está haciendo lo mismo con otro cliente, como el usuario A aún no ha grabado su factura se la adjudicaría el mismo, número, problema los detalles de ambos se confunden en una misma factura la 801.

Incluso utilizando una tabla axiliar de facturas pendientes de grabar, cuando decidamos enviar la factura al servidor nadie nos garantiza que vaya a ser la 801, se nos ha podido adelanter el Usuario A, C....

El usuario A, puede ocurrir que el vendedor le diga que cancele la factura, como el detalle ya se ha grabado, para poderla cancelar realmente tendríamos que eliminar (Delete) todas las líneas que ya habían sido grabadas, puesto que involuntariamente al pasar a la segunda línea se graba la primera.

Conclusión para mí, el número de la factura solamente lo sabemos cuando vaya a grabarse el tiempo que tardemos en grabar, pueden haberse grabado 10 facturas y el número que creíamos que tenía nuestra factura habra aumentado...

Claro que otras soluciones, pueden ser "In Memory Tables", ClienteDataset, o incluso que en cada PC, puede haber una tabla temporal de facturas y que solamene cuando el usuario confirme la grabación de la misma se envíe al servidor, para mí en este orden:

1.-Vamos al servidor, aumentamos, si nos deja, el número, sino como te decían sigues intentando y cuando obtengamos el número para nuestra factura, puesto que el siguiente que llegue ya tendría uno más.

2.-La enviamos al servidor con el número obtenido.

Siempre hay que tener en cuenta que trabajando en red, puede haber por ejemplo 10 personas facturando a la vez.

Y el primero que empieza la factura puede acabarla el último o incluso cancelarla, por lo tanto y para finalizar, solamente cuando se confirme la grabación podremos adjudicarle el número que le corresponde.

Un Saludo.

es tan simple como que asignes numero que corresponde al final de la transaccion o sea al dar el boton grabar, de otra forma es imposible ya que si cancelas te puede dejara un numero saltado, lamentablemente si lo quieres de otro modo deberas ser un vidente para saber si el usuario confirmará o cancelara tu facturas

Saludos.

La verdad es que en Paradox, no podemos hablar de grandes cosas en cuanto a transaciones.

Por eso propongo ese método, que por otra parte funciona correctamente, el número que tenemos en la tabla auxiliar es de la última factura grabada, y cuando asignamos uno nuevo es solamente por el usuario confirmo la grabación.

Un Saludo.