XL 2019 Pb de valeurs récupérées par une requête SQL en VBA

tibofo

XLDnaute Nouveau
Bonjour,
J'applique une requête SQL trouvée sur le forum.
Elle marche bien MAIS pour certains champs, les résultats obtenus sont étranges.


Exemple : dans ma BDD SQL j'ai un champ SMALLINTEGER où il n'y a que des 0. Dans Excel, j'obtiens 00/01/1900
un autre champ SMALLINTEGER, côté SQL SERVEUR, il y a des 1 --> excel récupère 01/01/1900
un autre champ en INTEGER, côté SQL SERVEUR, il y a 5463 --> excel récupère 15/12/1914
un autre champ typé DATETIME côté SQL SERVEUR, il y a 2020-06-22 00:00:00.000 (date format anglais) --> Dans Excel, j'obtiens 22/06/2020

Auriez-vous une idée de ce que je dois améliorer pour que ce soit les mêmes valeurs qui arrivent dans Excel ?

Merci
Thibauly


VB:
Dim Cn As ADODB.Connection
Dim Server_Name As String
Dim Database_Name As String
Dim User_ID As String
Dim Password As String
Dim SQLStr As String
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
Dim NUMEROBL As String



Server_Name = "TFR-PORT\instance"
Database_Name = "bdd"
User_ID = "sa"
Password = "xxxxxxxxx"


NUMEROBL = "BL1900852"

SQLStr = "SELECT * FROM [Z_VUE2] WHERE [NUMDOC]= '" & NUMEROBL & "'"


Set Cn = New ADODB.Connection
Cn.Open "Driver={SQL Server};Server=" & Server_Name & ";Database=" & Database_Name & ";Uid=" & User_ID & ";Pwd=" & Password & ";"
rs.Open SQLStr, Cn, adOpenStatic

   ' Cn.Open "Driver={SQL Server};Server=" & Server_Name & ";Database=" & Database_Name & _
   ' ";Uid=" & User_ID & ";Pwd=" & Password & ";"


With Worksheets("FEUILSQL").Range("a1:z500")
.ClearContents
.CopyFromRecordset rs
End With

rs.Close
Set rs = Nothing
Cn.Close
Set Cn = Nothing
 

Hasco

XLDnaute Barbatruc
Repose en paix
Bonjour,

Vous avez Excel 2019, utilisez donc PowerQuery (onglet données) pour rapatrier/transformer vos données !

Sinon donnez simplement un format standard ou nombre à vos cellules de colonne A et le format personnalisé : "aaaa-mm-jj hh:mm:ss,000"

cordialement
 
Dernière édition:

tibofo

XLDnaute Nouveau
Bonjour,

Vous avez Excel 2019, utilisez donc PowerQuery (onglet données) pour rapatrier/transformer vos données !

Sinon donnez simplement un format standard ou nombre à vos cellules de colonne A et le format personnalisé : "aaaa-mm-jj hh:mm:ss,000"

cordialement

Merci mais je souhaite aller plus loin avec le VBA : mes données reçues de SQL seront utilisées pour générer un fichier txt qui sera traité sous une autre forme que le simple colonnage. Le tout sera utilisé dans du Excel 2013, EXcel 2016 ou Excel 2019.
 

tibofo

XLDnaute Nouveau
Merci

J'ai finalement fais le choix de changer le format des quelques colonnes d'excel où les données en provenance de SQL s'affichaient bizarrement .
Au moins, cela me remet des données conformes à l'origine SQL SERVEUR.


VB:
.NumberFormat = "General"
 

tibofo

XLDnaute Nouveau
bonjour,
fais ce teste et regarde dans la fenêtre d’exécution raccourci clavier [CTRL] + [g]
VB:
With Worksheets("FEUILSQL").Range("a1:z500")
.ClearContents
Debug.Print Rs.GetString
.CopyFromRecordset rs
End With


Il y a un truc bizarre qui se produit en ajoutant Debug.Print rs.GetString

La fenêtre Espion m'affiche bien les bonnes valeurs.
Par contre l'exécution de .CopyFromRecordset rs ne copie plus rien ensuite

si je mets debu.Print.... en commentaire. cela copie de nouveau dans excel
 

tibofo

XLDnaute Nouveau
Il faut mettre ta plage au format standard
oui c'est normal RS est a eof après le getstring


C'est comme si le debug.print vidait le recordset
Si je fais cela :
VB:
Debug.Print rs.GetString
Debug.Print "2ème essai"
Debug.Print rs.GetString

j'ai une erreur sur le 2ème debug.Print
Erreur 3021 BOF ou EOF est égal à True ou l'enregistrement actuel à été supprimé
 

_Thierry

XLDnaute Barbatruc
Repose en paix
Bonjour à tous !


J'ouvre ce fil et que vois-je .....

Server_Name = "TFR-PORT\instance"
Database_Name = "bdd"
User_ID = "sa"
Password = "xxxxxxxxx"

Horreur et Damnation !

SA est le Super Administrateur en Database Log-In qui s'installe par défaut (en secours) lors du déploiement d'un serveur SQL. C'est en quelque sorte le "grand manitou" en cas de gros problèmes avec les Windows Authentication des Adminstrateurs ou des comptes de Services SQL.
En général SA ne sert jamais dans l'exploitation. On le garde "au chaud" dans un "coffre-fort" au cas où...

  • Utiliser SA pour une simple requête ADO Select est une abérration.
  • Avoir le pasword de SA en clair dans un module de VBA est une énorme faille de sécurité.

Si j'ai un conseil à te donner, demande d'urgence à ton SQL DBA de créer un compte Database Login (si vous ne pouvez le faire en SSO Windows Log-In, plus sécure) qui serait un "utilisateur virtuel" (Compte de service) avec des droits juste "Public" pour la connexion à la Database et de Read Only QUE sur la Table et/ou la Vue en question....
Imagine qu'avec SA on peut tout simplement prendre la main sur la totalité du serveur SQL ! Et détruire ou modifier absolument tout et en quelques scripts SQL trouvés sur le NET ! (Et je parle pas de hackers)

Un homme averti en vaut deux !

Bonne continuation
@+Thierry
 

tibofo

XLDnaute Nouveau
Bonjour à tous !


J'ouvre ce fil et que vois-je .....



Horreur et Damnation !

SA est le Super Administrateur en Database Log-In qui s'installe par défaut (en secours) lors du déploiement d'un serveur SQL. C'est en quelque sorte le "grand manitou" en cas de gros problèmes avec les Windows Authentication des Adminstrateurs ou des comptes de Services SQL.
En général SA ne sert jamais dans l'exploitation. On le garde "au chaud" dans un "coffre-fort" au cas où...

  • Utiliser SA pour une simple requête ADO Select est une abérration.
  • Avoir le pasword de SA en clair dans un module de VBA est une énorme faille de sécurité.

Si j'ai un conseil à te donner, demande d'urgence à ton SQL DBA de créer un compte Database Login (si vous ne pouvez le faire en SSO Windows Log-In, plus sécure) qui serait un "utilisateur virtuel" (Compte de service) avec des droits juste "Public" pour la connexion à la Database et de Read Only QUE sur la Table et/ou la Vue en question....
Imagine qu'avec SA on peut tout simplement prendre la main sur la totalité du serveur SQL ! Et détruire ou modifier absolument tout et en quelques scripts SQL trouvés sur le NET ! (Et je parle pas de hackers)

Un homme averti en vaut deux !

Bonne continuation
@+Thierry

Merci à vous 3 pour vos aides respectives.

Merci à Thierry pour ce rappel de sécurité que j'apprécie vraiment. Pour l'instant, je ne suis que sur mon PC qui me fait aussi office de serveur SQL mais uniquement à mon niveau. Mais j'en prends bonne note.
 

Discussions similaires

Statistiques des forums

Discussions
311 709
Messages
2 081 769
Membres
101 816
dernier inscrit
Jfrcs