ADORDD terminó versión en
https://github.com/AHFERREIRA/adordd.git
Google Translator:
ADORDD Consumado es!
No tengo planes para añadir nuevas funcionalidades a la misma.
Su ahora trabaja como cualquier otro rdd dbfcdx tipo y le permite al puerto de su aplicación en minutos (tiempo para cargar tablas) a cualquier SQL.
A partir de ahora única publicar nuevas versiones para corregir errores.
Todos sus comentarios, experiencias, ideas e informes de errores son más bienvenidos!
Nuevas características:
1) ADO_EXIT llamado internamente para cerrar todos los cuadros y las conexiones cuando planees salir de la aplicación.
2) abandonó la idea de conjuntos de registros persistentes para abrir enormes conjuntos debido a que la diferencia en la velocidad de apertura su perdido por completo su cierre (guardarla) en lugar de eso he hecho un nuevo conjunto.
SET ADO CACHESIZE A 100 ASYNC EN ASYNCNOWAIT EN
Este conjunto tiene un enorme impacto en el rendimiento de apertura enormes mesas.
Jugando con este conjunto podría mejorar significativamente el tiempo de apertura, pero entonces usted podría no tener todas las filas disponibles de inmediato.
Usted tiene que probarse a sí mismo si su aplicación funciona bien con las diferentes opciones.
principal problema ADORDD está abriendo mesas enormes sin cláusula where haciendo que cargar todas las filas.
Esto trae problemas con el tiempo de carga y el consumo de memoria.
Por otra parte por favor, recuerde que este sería el tiempo de carga más lento de una mesa, no importa si usted tiene 1 o 200 usuarios opuestas para dbfcdx tipo de DDR.
Esto no es una práctica estándar en SQL, pero para mantener la compatibilidad hacia atrás con nuestras aplicaciones tenemos que hacerlo Me gusta esto.
En aplicaciones donde no hay ningún archivo histórico y todos los datos se mantienen en las mesas de trabajo la única alternativa es o bien para pasar datos antiguos de los archivos históricos o utilice USO CTable DONDE cláusula where.
Si usted no puede hacer ninguna de ellas y tiene enormes mesas ADORDD podría no ser para usted y en _ la única alternativa para ir a SQL es ADS por lo que yo sé (manteniendo casi mismo código de aplicación).
La única solución para esta limitación es la construcción de una clase de acceso al SQL a través del interfaz C (HDO de Expósito por ej).
ADORDD puede trabajar con cualquier otra clase, siempre y cuando los pocos métodos y utilización ADORDD datos de MS ADO son replicado en esa clase.
Esta clase podría construir los decorados en un local de archivos dbf, matrices, etc.
