none
Qué tipo o version de Windows usar con SQL Server RRS feed

  • Pregunta

  • Hola.

    Desde hace ya algo mas que un año, vengo utilizando un sistema instalado con 1 servidor y dos terminales. Esto esta en un negocio de mucho movimiento de ventas de mostrador, tal como una farmacia muy popular.

    Utilizo en el servidor SQLServer 2012 pero completo, no es ninguna versión ligera. 

    Mi sistema hecho con codigo VB.NET y herramientas de terceros (DevExpress v15.1)

    Uso Windows 10 Pro 64 bits en todas las maquinas, incluyendo el servidor.

    Sucede que el sistema tiene comportamientos extraños, fuera de toda lógica, donde algunas veces y muy a azar, deja de grabar alguna factura o algún ítem de la factura, así mismo, cualquier actualización a la BD. Sin existir algún patrón a seguir para entender.

    Hoy, descubri, que en una maquina nueva instalada, el sistema funciona correctamente, menos los reportes. Es decir, el reporteador de DevExpress no funciona, sin causas a la vista. La misma copia del programa, funciona en todas las demas maquinas con las mismas caracterristicas, menos en esa.

    Yo pregunto, seria bueno que cambiase el Windows, para que sea gestionado todo de mejor forma, mas en el caso de acceso a la BD por la red?

    Me recomendaron hace tiempo utilizar Windows Server 2008, pero, no lo conozco.

    Que me recomiendan usar en este caso, como sistema operativo con respecto al acceso a datos?

    Gracias.

    sábado, 19 de mayo de 2018 2:18

Todas las respuestas

  • La recomendación es que no te centres en el Windows. Por los síntomas que describes, hay algún problema con el software. Puede ser una condición de carrera, un problema de concurrencia, o alguna cosa por el estilo. Este problema ocurrirá exactamente igual con independencia de la versión de Windows en los puestos y en el servidor.

    No hagas caso de la recomendación de usar Windows Server 2008. Puede que fuera una buena recomendación en el año 2008, pero ahora ya esa versión está obsoleta, y vas a tener problemas con el mantenimiento. Si vas a cambiar alguna versión, cambia hacia alguna reciente, no hacia una antigua. En el caso de un server, sería Windows Server 2016.

    sábado, 19 de mayo de 2018 6:00
  • Con Windows 10 en los equipos recomiendo que instales controladores nuevos bajados del sitio del fabricante de la tarjeta, porque Windows 10 al actualizarse pone controladores genéricos. No uses clic derecho Actualizar, sino con controladores nativos del fabricante.
    El el caso de que uses Win10 como host del SQL server, pues no vería problema si no excedes la cantidad de conexiones que permite, el caso es que no debes usar ese pc "server" para uso de escritorio. Es decir, está bien que lo uses en el servidor, pero que nadie se siente a usarlo, se supone que debe ser dedicado a las tareas de host.

    sábado, 19 de mayo de 2018 21:39
  • ¿Qué SQL Server hay actualmente?

    Tampoco vovlerse loco, está MySQL y Orecle SQL.


    http://electronica-pic.blogspot.com

    sábado, 19 de mayo de 2018 22:15
  • Puede ser una condición de carrera,

    Qué es eso? Disculpa Alberto, fue lo único que no capté.

    Y sí, claro que si cambiaría a un server pues sería con el 2016.

    Gracias.

    domingo, 20 de mayo de 2018 1:02
  • Una condición de carrera se produce cuando varios hilos de ejecución acceden a la misma información, sin utilizar bloqueos para retenerse los unos a los otros. Si uno de los hilos lee o modifica un dato o combinación de datos que otro hilo se encontraba leyendo o modificando en ese momento, los resultados son imprevisibles, y se puede producir cualquier error o pérdida de información. Se llama "condición de carrera" porque depende de cuánto corra cada uno de los hilos, para que dé la casualidad de que precisamente coincidan a la vez sobre un dato crítico. Puede ser que la mayor parte de las veces no coincidan, y por tanto que casi siempre aparente funcionar bien, pero muy de vez en cuando se produzca esa coincidencia dando lugar al error esporádico.

    Cuando hablamos de "varios hilos" suele pensarse un un único programa multihilo, y al decir "un dato" se piensa en una variable en memoria a la que acceden esos hilos. Pero el mismo principio también es aplicable a varios programas ejecutándose en equipos distintos que acceden a un dato compartido externamente, como por ejemplo un archivo en disco o unos registros en base de datos. En estos casos, el "fallo" no es culpa ni del archivo en disco ni de la base de datos, sino del programa que no utilizó los mecanismos de bloqueo adecuados antes de acceder a ese recurso compartido.

    domingo, 20 de mayo de 2018 9:38
  • Muchas gracias JoseMiel.

    Ese es un super dato que voy a tomar en cuenta y realizar.

    lunes, 21 de mayo de 2018 2:04
  • Gracias Alberto.

    Como enumeraste ese termino junto al de "..un problema de concurrencia", que considero es sinónimo, pues me rasque un poco la calva y dudé. Pero es así como indicas y voy observar una vez mas esos procedimientos que, a mi entender, no debería haber problemas de ese tipo, puesto que el error ha sucedido incluso, cuando no hay riego alguno de concurrencia ni carrera, porque se encuentra trabajando un solo punto.

    Gracias.

    lunes, 21 de mayo de 2018 2:09
  •  "..un problema de concurrencia", que considero es sinónimo

    No, no es sinónimo. Lo del problema de concurrencia se refiere, por ejemplo, al caso en que te traes una serie de datos desde la base de datos a una estructura en memoria, tal como un datatset, haces algunos cambios en el dataset, y luego lo vuelves a salvar a la base de datos. Si mientras tanto alguien ha hecho cambios en la base de datos, al salvar esos datos modificados se "machacan" los cambios que había en el servidor, perdiendo información. Esto puede ocurrir desde un único puesto, si se pasa por una rutina que lee datos, luego por otra que modifica datos, y luego otra que salva los que se leyeron al principio.
    lunes, 21 de mayo de 2018 5:43