Actualizar modelo .edmx con los cambios de la base de datos

La realización de cambios en la base de datos debe reflejarse dentro del modelo generado en Visual Studio. Desde un cambio mínimo, por ejemplo un campo de una tabla determinada pasa a admitir valores nulos, a cualquier otro complejo de adición/modificación/eliminación de tablas, referencias, triggers, procedimientos, relaciones…

1.- Abrimos nuestro archivo edmx con el editor predeterminado de Visual Studio: ADO.NET Entity Data Model Designer y pulsamos con el botón derecho sobre una zona libre en la opción «Udate Model from Database»

2.- Una vez que tenemos nuestro modelo reflejado, actualizamos el fichero con extensión «IntranetModel.TT» pulsando con el botón derecho sobre ellos y seleccionado «Run custom tool»

3.- Lanzamos «Run custom tool» sobre el fichero «IntranetModel.context.TT»

En el caso de haber cambiado el namespace o el nombre del proyecto, deberemos renombrarlos de nuevo en el archivo CS correspondiente del context de la clase. Tambien es posible realizar cambios parciales en partes concretar del modelado desde «Model browser«.

NOTA 1: Si a pesar de ello, no se reflejan los cambios, podemos eliminar ambos ficheros y volver a añadir «Add code generation item» seleccionando la versión correspondiente de «EF 6.x DbContext Generator»

NOTA 2: En ocasiones al actualizar un tipo de dato, es posible que no se refleje correctamente en el modelo EDMX, por ejemplo, el paso de un campo de string a bintint (int64). Revise manualmente los posibles cambios y vuelve a realizar el proceso.

Firebird: conexión fallida

Todavía hay aplicaciones que necesitan interoperabilidad, con bases de datos de Firebird, desde herramientas de Office u otros orígenes de datos; puede realizarse desde ODBC (Open DataBase Connectivity), debemos asegurarnos si la aplicación es de 32 o 64 bits, en ambos casos es posible instalar el driver desde la página oficial, es posible tener los dos instalados sin problema. Si ya disponemos de una versión podemos aprovechar para actualizarla y forzar la instalación de la que nos falte:

Desde línea de comandos y el directorio de instalación de la versión, por ejemplo para la versión de 32 bits:

instclient.exe install gds32
instclient.exe install fbclient

Estos comando copiaran y registraran las librerías FBLCIENT.DLL y GDS32.DLL en la carpeta C:\Windows\System32 para 32 bits y c:\Windows\SysWOW64 para 64 bits según cada caso

Igualmente es posible añadir el registro de Windows desde el mismo directorio mediante el comando:

instreg install

Para determinar la versión de la base de datos mediante el comando, se muestra On Disk Structure (ODS):

gstat.exe -h midatabase.gdb
ODSVersión
10.0Firebird 1.0
10.1Firebird 1.5
11.0Firebird 2.0
11.1Firebird 2.1
11.2Firebird 2.5

ACTUALIZADO: si el cliente necesita tener instaladas las versiones de 32 y 64 al mismo tiempo, para un servidor se puede configurar un puerto diferente haciendo una instalación manual. Para una estación cliente se puede instalar la versión de ejecutable «Classic Server» en lugar de «Super Server» lo que permitirá en la configuración posterior «Ejecutar como una aplicación» para no tener siempre el servicio iniciado y activado la casilla de «¿Copiar librería cliente como GDS32.DLL para soporte de aplicaciones antiguas?»

firebird_gds32_classic_01 sobre 2016
firebird_gds32_classic_02 sobre 2016

Evento 17137 en bases de datos SQL Server

La configuración por defecto de una base dedatos en Microsoft SQL Server en sus diferentes versiones, permite descargar al servidor de la caché la propia base de datos cuando la propiedad «AUTO CLOSE» esta activada, se genera el evento:

«Event ID 17137 Source: MSSQL$NOMBREUSUARIO Starting up database ‘NombreDeLaBBDD'»

Es posible modificar el comportamiento desde SQL Management Studio, haciendo clic con el botón derecho sobre la base de datos, en Opciones indicar la propiedad «Auto Close» a False:

En las versiones SQL Express siempre aparece activado, en el resto desactivado, si el acceso es muy esporádico puede mantenerse en OFF
Listado de las BBDD con la propiedad activada:

SELECT name FROM master.sys.databases WHERE is_auto_close_on = 1

Cambiar mediante sentencia SQL:

ALTER DATABASE <NombreBBDD> SET AUTO_CLOSE OFF

 

Ficheros bak no aparecen en SQL Server

Al trasladar copias de seguridad de SQL Server e intentar restaurarlas desde una ubicación diferente a la predeterminada, desde el explorador de Management Studio (SMSS) aunque sepamos que dentro de una carpeta concreta están los ficheros pueden no aparecer, si no están asignados los permisos; deberemos asignar permisos de lectura por lo menos sobre el usuario «NT SERVICE\MSSQLSERVER» del equipo local donde se ejecuta la instancia (por defecto)

Cuenta con la que se ejecuta el servicio:

Asignación de permisos a la carpeta donde se encuentran las copias de seguridad:

Iniciar Microsoft SQL Server cuando todo falla

En ocasiones algunas instancias de base de datos pueden comportarse de forma errática, los motivos pueden ser diversos: falta de recursos, ataques, corrupción de datos… el primer paso es averiguar el origen y para ello podemos lograr arrancar los servicios en modo usuario único y con los recursos mínimos, para ello debemos añadir el parámetro «-f» desde el administrador de servicios o iniciar desde línea de comandos «net start «SQL Server (MSSQLSERVER)» /f /m »

Solo una conexión se permitirá pero logaremos evaluar más en detalle los posibles errores del servicio degradado.