Salut,
 
On a un croûton de Windows 2008 serveur + SQL 2008R2 qui tourne une application de E-Notebook (http://www.cambridgesoft.com/support/ProductHomePage.aspx?KBCatID=7)
Le windows et SQL n'étant plus maintenus, je me suis mis en tête de migrer ça sur une VM propre.
 
J'ai donc installé un server 2019 + SQL 2016.
J'ai pu migrer la base de donnée d'une machine à l'autre avec l'outil de microsoft mais par contre le soft de e-notebook n'arrive pas a retrouver ses petits, malgré l'installation du connecteur MSSQL 10 (si c'est bien comme ça qu'on appelle ça ?)
La base de donnée est bien configurée en mode de compatibilité 2008R2
 
Comme je ne suis pas du tout dans le monde MS SQL, est-ce qu'une application peut ne pas fonctionner sur du SQL plus récent que telle ou telle version ?
 
Comme le truc ne fonctionnait pas, j'ai aussi testé avec SQL 2012 mais ça ne va pas mieux.
 
Merci d'avance

Il y a plein de "fournisseurs de services" pour SQL Server
 
SQL Native Client
SQL OLE DB driver
Le provider ODBC
 
Ca va dépendre de quoi ton application a besoin.
 
Un problème classique notamment avec le SQL Native Client c'est la prise en charge des versions de TLS (1.0/1.1/1.2). Si le client est trop vieux et ne prend pas TLS 1.1 ou 1.2 en charge alors que la configuration de l'OS en face l'exige, ça marchera pas.
 
Vu que tu es passé sur un combo OS/SQL moderne...
 
https://support.microsoft.com/fr-fr [...] sql-server

 
C'est le SQL native client effectivement !
J'ai forcé l'installation du 2008 en plus de celui installé par SQL2016.
Tiens d'ailleurs, est-ce que ça peut poser des problèmes de mettre le client x64 plutôt que le x32 ?
 
Pour les version de TLS, il semblerait que SQL 2016 prenne en charge de 1.0 à 1.2. Mais du coup, est-ce que ça signifie que les connex vers un serveur SQL sont dans tous les cas chiffrées ? Est-ce que sur le 2008 il y aurait possibilité que les mecs aillent désactivé le TLS tout court et passe "en clair" ?
 
Merci pour ton aide

Contacte l'éditeur sinon ? Si ce soft n'est plus supporté, ils ont peut-être développé un remplaçant ?

J'ai testé , le mec m'a dit que le produit étant en fin de vie, "we don't have any clue on how to migrate that on a newer machine" ensuite il m'a proposé leur solution de remplacement cloud pwet pwet et quand j'ai regardé si c'était migrable, je suis tombé sur

Je les laisserai venir exporter 100Gb de merdier en pdf un par un

Okay on avance un peu. J'ai installé SQL Server 2014 SP3, importé les données et maintenant quand je lance le soft il voit bien le serveur mais me dit
 
"Error while setting up connection to central database, error while executing the SQL:Open login failed for the user XYZUser."
 
Le curieux de l'histoire c'est que quand j'ouvre le soft il me propose de mettre un login ou alors d'utiliser le compte admin local, ce que je fais. Sur l'ancien serveur ça fonctionne. J'ai aussi tenté avec un autre login mais ça ne fonctionne pas mieux.
 
Par contre, sur l'ancien serveur, l'instance SQL s'appelait  
SERVEUR2008\CODEXYZ alors que sur le nouveau c'est "SERVERNEW\SERVERNEW", je me demande si leur bouzin ne voudrait pas retrouver son CODEXYZ il y a moyen de renommer ça ?
 
Ha ! Fallait configurer le bouzin en mixed mode pour l'auth, ça a l'air de passer maintenant \o/
 
Merci

 
Ca dépend si ton application cliente s'exécute en 32 bits ou 64 bits.
 
Si l'application est 32 bits il faut impérativement le client 32 bits.
Si l'application est 64 bits a priori avec le Wow6432 de Windows elle devrait pouvoir utiliser le client 32 ou le 64. Je suis pas assez calé en SQL Server pour dire si y aurait des limitations avec le client 32 bits, par défaut je mettrais le 64 bits si l'application est 64 bits.

Alors l'application est probablement en 32 mais dans tous les cas le windows refuse d'installer le client 32bit donc j'ai mis l'autre.

Tiens et vu que je vais devoir refaire une synchro entre le vieux et le nouveau serveur avant mise en prod, quelle est la methode la plus propre ? Je relance l'outil de migration de Microsoft ?