Discussion :

[Pfeffer]

Bonjour à tous,

Je viens de tester une migration de ma BDD SQL Server dans AZure via un fichier bacpac.
En réalisant quelques tests je me suis vite rendu compte que j'ai un problème au niveau des dates:
Les requêtes paramétrées C# fonctionnent sans aucun soucis, par contre quand j'essaye de faire une requête toute simple avec des dates il faut que je la passe forcément au format anglais. Une idée d'ou peut venir le pb ?
Le cloud manager me dit que du côté settings de langage il ne voit qu'il peut modifier.

[SQLpro]

Lorsque vous avez créé vos compte d'accès, le paramétrage était il français ?

A +

[Pfeffer]

De quel compte on parle ? Les comptes SQL Database ?

[SQLpro]

Tous les comptes qui accèdent à la base.

A +

[Pfeffer]

Oui, je viens de regarder.
Sur mon SQL Server en VM, les comptes sont bien en français.

[SQLpro]

En ce qui concerne les types temporelles, il ne faut JAMAIS passer les valeurs avec un format spécifique à une langue, mais utiliser le format ISO qui outrepasse tous les paramétrages de langue.
Pour mémo, le format ISO ,est de deux types :

• ISO court 'AAAAMMJJ hh:mm:ss.nnn' pour le type DATETIME (norme SQL antérieure à SQL:1999)
• ISO long 'AAAA-MM-JJ hh:mm:ss...' pour les taypes DATETIME2, DATE, DATETIMEOFFSET (depuis la norme SQL:1999)

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
SET LANGUAGE English;
 
DECLARE @D DATETIME = '20211231', @D2 DATETIME2 = '2021-12-31';
SELECT @D, @D2;
GO
 
SET Language Français;
 
DECLARE @D DATETIME = '20211231', @D2 DATETIME2 = '2021-12-31';
SELECT @D, @D2;
GO
 
SET Language Russian;
 
DECLARE @D DATETIME = '20211231', @D2 DATETIME2 = '2021-12-31';
SELECT @D, @D2;
GO

A +

[Pfeffer]

Oui, les requêtes paramétrées en C# permettent de régler ce problème, mais nous avons des vieilles macro VBA (bad ) qui n'utilisent pas ce principe et c'est sur celles-ci que nous avons un problème.

Je viens de voir que SQL Azure Database est configurée en UTC, et que visiblement on ne peut pas changer cette config ..
1) Est ce que vous confirmez ?

Cela signifie que dans les TSQL partout ou on utiliser getDate() cela va récupérer le temps UTC alors que dans nos applications tout est configuré en LOCAL TIME Zone, ce qui me pose un autre problème

[SQLpro]

C'est normal l'UTC vu que vos serveurs SQL peuvent être hébergés dans n'importe quel pays sans que vous sachiez lequel ! Donc les dates sont toujours et systématiquement en UTC. Seule l'application peut envoyer des dates localisées...

je me tue à avertir mes clients depuis des décennies sur cette horreur des dates localisées qui complique la vie. Mieux vaut du DATETIMEOFFSET si vous voulez les deux.... par exemple allez donc calculer la durée en heure entre deux dates quand celle-ci sont à cheval sur la date de changement d'heure été/hiver ?
Pour information j'ai modélisé le système de gestion des crues au niveau national et la précédente version était basées sur des dates locales (en 2008).... Heureusement il n'y a pas eu d'épisode d'inondation aux moment des changements d'heures d'hiver/été, sinon ils auraient cru soit que la pluie avait cessée alors qu'il n'en était rien (absence de données), soit que la pluie redoublait (insertion double...), avec les conséquences humaines que cela peut entrainer !!!

A +

[Pfeffer]

Le problème de la 25è heure est bien connue est peut être gérer autrement (doubler la valeur, différencier la 25 è heure, etc.), mais je suis d'accord que de mettre des datetimesoffset c'est plus facile à gérer ensuite. Lais on hérite également de ce qu'on hérite !!
Est ce que dans une instance SQL Azure Mangée du coup j'aurai le même problème ? Par ce que là en l'état je peux pas basculer dans SQL Azure Database.

[Pfeffer]

Donc au FINAL !! Choisissez SQL Azure Database si vous partez sur un nouveau projet ...
Sinon restez en mode VM + SQL Server.

[SQLpro]

pas forcément, il y a pas mal de projet qui passent dans Azure parce que bien conçus au départ.... Un autre truc dans Azure : aucune table ne peut être sans PK....

A +

[Pfeffer]

C'est bien ce que je dis, si on part sur un nouveau projet et qu'on respecte les préconisations Azure, tout fonctionne.
Mais basculer une BDD et des applications créées avec des concepts d'avant Azure, c'est plus compliqué.

Les tables sans PK c'est pas trop gênant pour ma part, j'en ai pas

[SQLpro]

pas spécifiquement les nouveaux projets.... Par exemple SAGE à passer la plupart de ses logiciels dans Azure

A +

[Pfeffer]

Je parlais de basculer en AZURE PAAS, pour ma part je suis également dans AZURE mais en IAAS (VM + SQL Server)