Afecta EXTERNAL al rendimiento

[floren]

Pues eso, leyendo un hilo anterior se me ha encendido la bombilla sobre un par de problemillas que tengo, pero tento dudas de si al crear tablas en ficheros externos al .fdb puede caer el rendimiento o la integridad de los datos.

Gracias

[gendelphi]

Que tal.

Pues a ciencia cierta no lo se, pero pues yo creo que si, ya que probablemente la manipulación de los archivos externos no se haga haciendo uso de paginas, por lo tanto tampoco de memoria cache. Respecto a la integridad pienso que tambien no existe el mismo nivel de integridad en un archivo externo que en la misma base de datos. Pero repìto, es mi punto de vista, tendrias que checarte los fuentes, o la documentación de los fuentes para asegurarte.

Y a todo esto: ¿es muy necesario que uses archivos externos?, tanto como para que te preocupe el desempeño o la integridad. Yo te recomendaría te abstengas al maximo de su uso. En mi caso solo los uso para llevar algún registro (LOG) de actividades que ocurren en la base de datos o el servidor, o simplemente para exportación a archivos de texto plano, que aunque para ésto ultimo ya existen multitud de herramientas front-end.

[floren]

Hola Gendelphi, eso mismo pienso yo.

Lo que pasa es que tenemos una aplicación que va cerrando mes a mes, según haya hecho la contabilidad el usuario, pero si se equivoca en un mes después de haberla cerrado, nos manda el fichero de saldos (en paradox ahora mismo), y se lo volvemos a mandar habiéndole quitado el cierre, por lo cual puede hacer correcciones y volver a cerrar el mes.

Esta aplicación de contabilidad está aún en paradox y los otro módulos ya los vamos pasando a FB; está casi todo listo menos este pequeño detalle, de ahí sacar los saldos y que nos mandasen sólo un fichero pequeño... pero no estoy muy convencido (estoy de acuerdo contigo), sobre todo por falta de documentación; creo que el tratamiento en cuanto a localización de ficheros, clustering, etc. es más eficaz en SQL Server, ya digo que desconozco esto en FB.

Gracias por tu respuesta y hasta luego!

[jachguate]

nos manda el fichero de saldos (en paradox ahora mismo), y se lo volvemos a mandar habiéndole quitado el cierre

Creo que tu problema aqui es la forma en que que queres conseguir esto... Para lo que comentas no creo que sea necesario que viaje nada entre tu cliente y vos. Simplemente programá un proceso que tenga la lógica necesaria para "quitar el cierre", y que sea el mismo cliente quien lo ejecute. No te parece??

Hasta luego.

;)

[floren]

Hola Jachguate:

El problema que tenemos es que son sucursales que nos envían sus cuentas mensuales y las incorporamos a la contabilidad general. Piensa que si alguien cierra un mes, nos lo manda, y luego puede abrirlo sin problemas, entonces ya no "casan" su contabilidad y la nuestra.

De momento lo más fácil era que nos mandaran su fichero de saldos, comprobar que no estaban aún incorporadas las cuentas, y volver a mandárselos ya sin la información del mes cerrado.

Es una solución...

La otra que se me viene ocurriendo es realizar algún tipo de HASH sobre una secuencia aleatoria de números HEX, que el tío me los diga por teléfono o e-mail, y darle yo el resultado para que abra de nuevo el mes... no se me ocurre de momento otra cosa.

Gracias y saludos

[jachguate]

Para efecto de la reapertura de mes, podes idear un mecanismo por el que generes un archivo de "autorización" con algunos datos que el programa en el cliente pueda verificar, algun tipo de seguridad (tipo checksum o algo similar) y listo. Cada vez que necesiten reabrir un mes, te solicitan la autorización, que vos generas en un archivo en tu sistema, lo envias por mail, y con esto pueden ya proceder a la reapertura.

Hasta luego.

;)

[floren]

Sí, es otra idea y bastante buena, pero si te fijas la filosofía de fondo sigue siendo la misma, y es que se debe generar un mecanismo de autorización que pase por nuestro control.

Lo tendré en cuenta jachguate, gracias!

[jachguate]

La digo ahora, porque ese mecanismo de control no era evidente en un inicio, al menos para mi (parecia que se trataba de un cliente independiente y un servicio innecesario). Con esta segunda idea, mantenes el control, sin hacer viajar trozos de la base de datos por el email... :eek:

Hasta luego.

;)