Cita:
Empezado por LDD
Bueno gracias a todos, os amplío la situación :
- No es cuestión de si usar cable o wifi, no es opcional, HAY que usar WIFI, estamos hablando de tablets.
- Puede haber paredes o no, la cuestión es que a medida que nos separamos del rooter los paquetes se rompen más facilmente.
- Curiosamente la degradación sólo se da (o es mucho mayor) en operaciones sobre la base de datos de tipo Insert, Update, Delete; cuando hacemos SELECT el resultado es muy rápido, un poco más lento que si estamos junto al rooter pero muy aceptable.
- Gracias tmsanchez por el artículo enviado. Realmente funciona mejor si actualizo en el registro el valor de HKEY_LOCAL_MACHINE | System | CurrentControlSet | Services | Tcpip | parameters | TcpMaxDataRetransmissions y lo pongo a 1, pero entonces el programa peta en cuanto hay un paquete roto.
- Pensad que no hablo un único Insert sino de unos 30, uno tras otro.
Básicamente el problema parece que se da cuando los paquetes de datos que salen del cliente se "rompen" y este intenta enviarlos de nuevo (hasta 5 veces de acuerdo con la configuración Firebird.conf y de los valores de Registro), es como si se hiciera un lio de paquetes enviados y reenviados y se volviera muuuy lento hasta incluso bloquearse.
¿Hay una versión comercial de Firebird que gestione mejor esta situación?
Gracias por vuestro interés
|
Uno puede trabajar de una forma un poco distinta, aunque genera más trabajo de entrada, a futuro es algo muy bueno:
Entonces en vez de que nuestra aplicación se entienda directamente con TDataSets (o sus equivalentes TIBDataSet), es conveniente tener por lo menos dos aplicaciones, una estilo servidor la cual va a ser la única que juegue con la base de datos y que se encargue de transformar los TDataSets posibles en clases, por ejemplo en vez de tratar con un dataset llamado DSPersonas, se tenga una clase llamada Personas, al crear un objeto de dicha clase se va a tener toda la información que se tienen en un registro del dataset, luego si necesito tener la información de varias personas las podré almacenar en un TList, ahora al tener tanto el TList de personas, o al objeto Persona los puedo serializar y convertir en una cadena de texto, la cual es más eficiente a la hora de tratar con ella en una red, estas cadenas de texto son con lo que seguiremos tratando en la otra aplicación, en la cliente, cuando pida información al servidor, esta no va a pedir un DSPersona, va a tratar con las cadenas de texto e internamente las va a desserializar y convertir en un objeto Persona, si se hace algún cambio ese objeto persona se serializar nuevamente, se envía a la aplicación servidor, este habla con la base de datos y guarda la información en la tabla personas...
Como digo, es muy largo de hacer de entrada, si ya se tiene mucho hecho se ve como algo muy malo, pero se va notando como mejora en velocidad y estabilidad de una forma fantástica.