FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
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.
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
#2
|
||||
|
||||
Cita:
De todas maneras para este caso el problema es la calidad de conexion...
__________________
El malabarista. |
#3
|
||||
|
||||
Cita:
Lo del dataSet lo digo porque además suele tener mucha información. Y si es de alguna paleta estilo IBX, y un largo Etc va a tener otras cosas que lo pueden complicar trabajar serializado, o desconectado, o que traiga aún más información que no se use, al crear uno la clase y serializarla suelo tener más control de que estoy enviando, y soy más consciente que tanta información estoy enviando, al final esto a mi me significo ahorros escandalosos en trafico de red.
__________________
"Como pasa el tiempo..... ayer se escribe sin H y hoy con H" |
#4
|
|||
|
|||
Gracias a todos
Gracias a tod@s,
La verdad es que la WIFI , el router .. son de los mejores, no es problema de calidad de hardware. Tampoco debería ser problema de software ya que el mismo ha funcionado durante más de 15 años en entornos muy antiguos, eso sí NUNCA con WIFI. Seguramente acabaremos aplicando la solución que ya ha comentado RONPABLO de trabajar las transacciones enviado los fatos por FTP o cualquier otro sistema y haciendo que las operaciones de escritura emn la base de datos las realice un segundo programa en el servidor o en otro cliente conectado por cable. Mientras tanto estoy tratando de ver si Firebird 3.0 ha resuelto este problema, pero me doy de narices al tener ODS distintas, mi base de datos tiene la 11.2 y parece que Firebird 3.0 usa la 12.0, en fín ya os contaré. Gracias de nuevo |
#5
|
||||
|
||||
Como ha dicho antes otros compañeros y yo mismo, tenemos clientes trabajando por wifi con bastante más de 10 metros, sin problemas, con fb1.5, fb.2.1 y fb.2.5
|
#6
|
||||
|
||||
Pero si no quiere creer que puede ser problema de hardware...
Sin embargo, si antes iba bien y ahora con wifi va mal, es que algo del wifi no está bien. Por lógica. |
#7
|
||||
|
||||
La sugerencia de RONPABLO (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) es un buena idea. Donde yo trabajaba (en una entidad bancaria) el analista de microinformática para las aplicaciones en Oracle diseñó y desarrolló un sistema en el que los puestos enviaban "paquetes" de texto plano (SELECT, INSERT, etc.) a una aplicación en el servidor que era la que ejecutaba todo el tarbajo de BB.DD. y devolvía una ristra también en texto plano, con los pertinentes "caracteres de control" propios. Como era algo interno todos conocíamos que iba a devolvernos y como vendría estructurado. Por desgracia no dispongo de ese código.
Si recuerdo que cada una de las partes usaba dos puertos TCP. Por uno mandaba la orden y por el otro recibía la respuesta. Una vez afinado era un sistema altamente fiable y rápido. No era wifi pero por ponerte un ejemplo conectaba puestos de oficinas que distaban 400 y 500 Km. del servidor Oracle. Y lo que te comentan del "ruído" no es ninguna tontería: en un negocio de hostelería hay muchas máquinas (cubiteras, registradoras, receptores de TV, etc.) que degradan la señal. La opción de poner repetidores no es descabellada. |
#8
|
||||
|
||||
No hace falta reinventar la rueda. Con datasnap o mormot ya tenés todo lo necesario para una aplicación en capas
|
#9
|
||||
|
||||
Cita:
Algunos de mis viejos clientes tienen conexiones directas sobre internet con las distintas sucursales, en tiempo real, con firebird y componentes IBX. Otros conectan a un servidor web mediante wifi y es el servidor web el que conecta con el servidor de bases de datos firebird. Por ejemplo, también. |
#10
|
||||
|
||||
No estaba comparando tecnologías; simplemente comentaba que la idea de RONPABLO era buena independientemente de la tecnología empleada. Es cierto que el 99% de las conexiones que hacía mi banco era con protocolos de cable, pero las que se hacían inalámbricas también empleaban ese mismo sistema.
|
#11
|
||||
|
||||
Hola a todos.
La experiencia que yo estoy teniendo, y según lo que he comentado a otros colegas les pasa lo mismo, es que la wifi no es una buena opción para este tipo de menesteres. A nosotros nos pasa que, teniendo una instalación con wifi funcionando de forma correcta, en el momento en que el local se llena de gente (fines de semana) empiezan los problemas. ¿Solución? buscar puntos de acceso y tablets de calidad, es decir, que no valen las tablets "baratunas" ni los puntos de acceso convencionales. Nosotros siempre hemos instalado terminales vía radio (orderman) sin ningún tipo de problemas, pero el tema es que la tecnología wifi es bastante más barata y la gente la demanda queriendo que te de el mismo rendimiento que tecnologías tipo radio que son bastante más fiables y es cuando vienen los problemas. Nosotros estamos intentando encontrar puntos de acceso y tablets adecuados pero todavía no hemos dado con algo fiable. Cuando lo encontremos ya lo postearé por aquí. Saludos
__________________
Be water my friend. |
#12
|
||||
|
||||
Es que además se añade que cada vez más se exige "wifi gratis" en el local para los clientes, con lo que hay que compartir recursos con más gente. Eso o tener un equipo sólo para atender los accesos de los clientes y otro para el servicio del local.
|
#13
|
||||
|
||||
De hecho es una solución idónea.
|
#14
|
||||
|
||||
Disculpen la intromisión pero, ¿de verdad se necesita tanta parafernalia para tomar la orden de los comensales? Creo que algunos han comentado que debe revisarse el alcance e interferencias en la red wifi y me sumo a ellos. Creo que se le preguntó desde un principio si observaba la misma degradación en otros usos de internet y creo que no ha contestado. Por ahí habría que empezar.
// Saludos |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Mando a Distancia | sanluisme | Varios | 2 | 22-10-2012 19:22:13 |
FIrebird: Eliminar tablas segun un patron | apicito | Firebird e Interbase | 7 | 02-02-2012 10:33:09 |
Comportamiento diferente segun conexión LAN o WIFI | MON___ | Redes | 1 | 14-01-2008 23:12:50 |
Universidades a distancia | DarKraZY | Debates | 5 | 07-05-2006 13:01:41 |
trabajo a distancia | haron | Debates | 9 | 22-07-2004 05:34:42 |
|