Club Builder

[Angel]

Gracias por las sugerencias Alfredo. Tengo un problema por el que no podría usar IBConsole o herramientas externas: la aplicación va estar instalada en cinco ciudades diferentes, y yo sólo tengo acceso directo a una de ellas por lo que me interesa que todo se pueda crear desde la aplicación. De todas formas, echaré una ojeada a tu código.
_________________
Un saludo

Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA)

[Angel]

Me ha surgido un nuevo problema porque se ha producido una modificación en la base de datos. En un principio la aplicación se había diseñado para que se ejecutara de forma independiente de varios puestos situados en diferentes provincias y no iban a tener relación entre sí en ningún momento.

Sin embargo, el encargo se ha ampliado ya hora se me pide que se pueda importar los datos de todos las provincias a uno central, con el objetivo de centralizar los datos. No se va a trabajar contra un servidor común, al menos de momento. Ante esta circunstancia yo me he planteado modificar la base de datos incorporando además en el índice el campo Provincia; de esta forma podrán haber dos registros 1000 pero con un código adicional que los distinguirá (45/1000, 16/1000, etc.)

¿Se puede hacer que el procedimiento para generar el código tenga en cuenta la provincia a que se refieren los datos? El código de provincia es, en cualquier caso, un alfanumérico de dos posiciones. Tendría que ser algo así:

[Cesar C. Salazar Gonzalez]

Hola Angel: me es dificil imaginarme la estrucutra donde estas almacenando la base de datos.
pero algo que te puede ayudar son los campos ID, como anteriormente en muchos post, he comentado que estos campos son exclusivamente del programador y muy rara vez, salen a luz publica, el ID, es un campo que identifica de manera unica a un registro, no importando que este registro sea el primero o el utlimo generado. pero veo algo curioso te piden "concentrar" toda la informacion (aqui ya es un servidor remoto) pues bien, puedes seguir con el campo ID unico para cada uno. pero lo que si no se puede hacer, "copiar" literalmente los registros con los ID, la unica solucion favorable es que todas esas provicias las generes en un Servidor central, pues asi todas ellas contendran un unico ID que pueden manejarse en todas las estaciones.

Si lo que estoy explicando no es parte de tu tema, comentame o mejor aún explicame cual es el problema y aqui veremos como solucionarlo

Saludos.
_________________

[Angel]

Gracias César. Trataré de explicar el follón que tengo montado con más calma a ver si encuentro una solución.
_________________
Un saludo

Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA)

[Angel]

Primero que nada perdón por el rollo. A ver si puedo explicar un poco de que va esta aplicación y por qué se está haciendo así.

Actualmente se está usando una aplicación desarrollada en Builder con tablas Paradox, desarrollada a partir de una anterior en CA Clipper. La aplicación corre en red en cada una de las instalaciones hechas pero las bases de datos están aisladas; actualmente hay dos instalaciones que están usándola al 100% y una tercera que la utiliza parcialmente.

Ante la degradación de los datos en las tablas Paradox, me plantee migrar a un sistema con tablas Firebird o MySql, eligiendo finalmente el primero de ellos pero con las mismas características de uso de bases de datos aisladas. El problema ha surgido cuando se me ha pedido la posibilidad de concentrar dichas bases de datos en único equipo, con fines de consulta únicamente.

Dado que por razones económicas no es viable de momento establecer un servidor de datos común para las cinco instalaciones que van a haber, no me queda más remedio que plantear la exportación de datos desde las cinco instalaciones a ese equipo central.

Las tablas principales de la aplicación tienen, en lo esencial, esta estructura:

Personas


Código:

CREATE TABLE Personas (CodProv CHAR(2), Registro INTEGER, Apellidos CHAR(40), Nombre CHAR(15), ... PRIMARY KEY (CodProv, Registro))


Recibos


Código:

CREATE TABLE Recibos (CodProv CHAR(2), Registro INTEGER, C_refer CHAR(12), Fecha DATE, RefInt CHAR(10), ... PRIMARY KEY (CodProv, Registro, C_refer, Fecha, RefInt))

El campo Registro de la tabla Personas es el único que necesito que sea autoincremental; es equivalen al ID que habéis citado por aquí. Como las bases de datos no van a estar conectadas entre sí, al importarlas a una máquina común podrán haber, y de hecho será así con frecuencia, hasta cinco registros con el mismo ID; para evitar ese problema fue por lo que incluí el campo CodProv (código provincial) en la definición del índice. Podrán existir entonces tantos registros con el mismo ID como códigos provinciales haya: 16/1000, 45/1000...

Ahora, para el campo autoincremental, tengo lo siguiente:

[Tor]

Hola Angel.
Espero haber comprendido tu problema, te planteaste la posibilidad de que en la pc que se van a centralizar los datos estas esten en bases de datos distintas asi cada bd corresponderia a una provincia y no tendrias probleamas con los id duplicados. Tu aplicacion que analiza los datos centralizados na cambiaria mucho ya que tiendria que realizar consultas a mas de una bd. yo uso MySQL y un select quedaria algo asi

[Angel]

Gracias Tor. Con las select, vistas y demás no tengo problema. Me basta con incorporar ese dato al query y donde antes ponía:

[Tor]

ok fijate en libro "la cara oculta de c++ builder", hay un capitulo de "procedimientos almacenados y triggers" cap 6, encontras algunos detalles de los generator. con algunos ejemplos. bye
saludos tor

[Cesar C. Salazar Gonzalez]

aun que la solucion, pueda darse de esta manera, que te comentan en la parte arriba, partmos que la informacion y la tablas ya contienen registros.
Antes de moverle a todo realiza la prueba siguiente, de convertir el registro = ID que estas planteando en una manera mas sencilla de convertirlo a un tipo varchar de 11 creo pues los integeres asi se manejan al convertirlos a varchar.

y realizar los siguiente.

registro = (procedimiento que te devuelvel el ID)+la privincia

convirtiendo estos dos campos o valores en String o AnsiString
quedando elregistro algo asi
registro = "1000-45"
con esto mantienes el ID=registro anterior y aun asi le puedes incrementar el otro valor.

antes de moverle genera una prueba pues puede que al convertir los valores del ID estos puedan ser borrados.

Saludos.

nota: la conversion del campo puedes hacerlo Via EMS para que tengas un mayor control
_________________

[Angel]

Gracias a ambos por las sugerencias. EL libro, la verdad sea dicha, ni me acordaba de él y eso que lo tengo literalmente delante mis narices

César: Esa idea era la otra alternativa que se me había ocurrido, invertir el orden del ínidce. Lo probaré y ya os diré como me ha ido.
_________________
Un saludo

Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA)