Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Arnaud CLERET
Tout dépend de la précision souhaitée et des contraintes de volumétrie. Les différences entre les deux types : - datetime : - Du 1er janvier 1753 au 31 décembre 9999 - Précision : 3,33 millisecondes - Stockage sur 4 octets - smalldatetime : - Du 1er janvier 1900 au 6 juin 2079 - Précision : 1 minute - Stockage sur 2 octets
-- arno - http://www.dotnetguru2.org/acleret/
"okpwal" a écrit dans le message de news:
Bonjour, Tout est dans le titre, hors mis l'espace occupé, y a-t-il un avantage quelconque à préférer l'un ou l'autre ? G.
-- okpwal la perdrix !
Tout dépend de la précision souhaitée et des contraintes de volumétrie.
Les différences entre les deux types :
- datetime :
- Du 1er janvier 1753 au 31 décembre 9999
- Précision : 3,33 millisecondes
- Stockage sur 4 octets
- smalldatetime :
- Du 1er janvier 1900 au 6 juin 2079
- Précision : 1 minute
- Stockage sur 2 octets
--
arno - http://www.dotnetguru2.org/acleret/
"okpwal" <okpwal@wanadoo.fr> a écrit dans le message de news:
mn.2d7b7d645fef1d5b.43908@wanadoo.fr...
Bonjour,
Tout est dans le titre, hors mis l'espace occupé, y a-t-il un avantage
quelconque à préférer l'un ou l'autre ?
G.
Tout dépend de la précision souhaitée et des contraintes de volumétrie. Les différences entre les deux types : - datetime : - Du 1er janvier 1753 au 31 décembre 9999 - Précision : 3,33 millisecondes - Stockage sur 4 octets - smalldatetime : - Du 1er janvier 1900 au 6 juin 2079 - Précision : 1 minute - Stockage sur 2 octets
-- arno - http://www.dotnetguru2.org/acleret/
"okpwal" a écrit dans le message de news:
Bonjour, Tout est dans le titre, hors mis l'espace occupé, y a-t-il un avantage quelconque à préférer l'un ou l'autre ? G.
-- okpwal la perdrix !
okpwal
> Tout dépend de la précision souhaitée et des contraintes de volumétrie. Les différences entre les deux types : - datetime : - Du 1er janvier 1753 au 31 décembre 9999 - Précision : 3,33 millisecondes - Stockage sur 4 octets - smalldatetime : - Du 1er janvier 1900 au 6 juin 2079 - Précision : 1 minute - Stockage sur 2 octets
merci.
-- okpwal la perdrix !
> Tout dépend de la précision souhaitée et des contraintes de volumétrie.
Les différences entre les deux types :
- datetime :
- Du 1er janvier 1753 au 31 décembre 9999
- Précision : 3,33 millisecondes
- Stockage sur 4 octets
- smalldatetime :
- Du 1er janvier 1900 au 6 juin 2079
- Précision : 1 minute
- Stockage sur 2 octets
> Tout dépend de la précision souhaitée et des contraintes de volumétrie. Les différences entre les deux types : - datetime : - Du 1er janvier 1753 au 31 décembre 9999 - Précision : 3,33 millisecondes - Stockage sur 4 octets - smalldatetime : - Du 1er janvier 1900 au 6 juin 2079 - Précision : 1 minute - Stockage sur 2 octets
merci.
-- okpwal la perdrix !
Patrice
Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait pas car la précision du DateTime était supérieure à la précision côté client (et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
-- Patrice
"okpwal" a écrit dans le message de news:
Bonjour, Tout est dans le titre, hors mis l'espace occupé, y a-t-il un avantage quelconque à préférer l'un ou l'autre ? G.
-- okpwal la perdrix !
Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait
pas car la précision du DateTime était supérieure à la précision côté client
(et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
--
Patrice
"okpwal" <okpwal@wanadoo.fr> a écrit dans le message de news:
mn.2d7b7d645fef1d5b.43908@wanadoo.fr...
Bonjour,
Tout est dans le titre, hors mis l'espace occupé, y a-t-il un avantage
quelconque à préférer l'un ou l'autre ?
G.
Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait pas car la précision du DateTime était supérieure à la précision côté client (et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
-- Patrice
"okpwal" a écrit dans le message de news:
Bonjour, Tout est dans le titre, hors mis l'espace occupé, y a-t-il un avantage quelconque à préférer l'un ou l'autre ? G.
-- okpwal la perdrix !
okpwal
> Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait pas car la précision du DateTime était supérieure à la précision côté client (et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
Est-ce qu'il faudrait alors tout basculer en DateTime si l'argument taille n'est pas un obstacle ?
-- okpwal la perdrix !
> Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait
pas car la précision du DateTime était supérieure à la précision côté client
(et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
Est-ce qu'il faudrait alors tout basculer en DateTime si l'argument
taille n'est pas un obstacle ?
> Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait pas car la précision du DateTime était supérieure à la précision côté client (et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
Est-ce qu'il faudrait alors tout basculer en DateTime si l'argument taille n'est pas un obstacle ?
-- okpwal la perdrix !
Patrice
Je voulais dire que ce qui prime avant tout est la précision nécessaire à l'application (donc tout simplement choisir SMALLDATETIME si la précision est suffisante, DATETIME sinon).
L'auttre commentaire est que j'avais vu il y a bien longtemps (voire au siècle dernier !) quelqu'un avoir un problème sur le verrouillage optimiste à cause d'une trop grande précision dans les données DATETIME (il reste possible de tronquer légèrement les valeurs si le cas osait encore se produire encore de nos jours, je ne veux pas dire que DATETIME n'est pas utile).
En résumé, je pense qu'il faut avant tout voir de quoi a besoin l'application plutôt que de rentrer dans des considérations que je trouve oiseuses (par exemple quelq'un pourrait te dire que sur un processeur 32 bites et datetime étant stocké sur 4 octets, choisir datetime au lieu de smalldatetime qui serait pourtant suffisant te fera gagner de très importantes microsecondes, si, si ! etc...).
-- Patrice
"okpwal" a écrit dans le message de news:
Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait pas car la précision du DateTime était supérieure à la précision côté client (et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
Est-ce qu'il faudrait alors tout basculer en DateTime si l'argument taille n'est pas un obstacle ?
-- okpwal la perdrix !
Je voulais dire que ce qui prime avant tout est la précision nécessaire à
l'application (donc tout simplement choisir SMALLDATETIME si la précision
est suffisante, DATETIME sinon).
L'auttre commentaire est que j'avais vu il y a bien longtemps (voire au
siècle dernier !) quelqu'un avoir un problème sur le verrouillage optimiste
à cause d'une trop grande précision dans les données DATETIME (il reste
possible de tronquer légèrement les valeurs si le cas osait encore se
produire encore de nos jours, je ne veux pas dire que DATETIME n'est pas
utile).
En résumé, je pense qu'il faut avant tout voir de quoi a besoin
l'application plutôt que de rentrer dans des considérations que je trouve
oiseuses (par exemple quelq'un pourrait te dire que sur un processeur 32
bites et datetime étant stocké sur 4 octets, choisir datetime au lieu de
smalldatetime qui serait pourtant suffisant te fera gagner de très
importantes microsecondes, si, si ! etc...).
--
Patrice
"okpwal" <okpwal@wanadoo.fr> a écrit dans le message de news:
mn.35167d64e45a6303.43908@wanadoo.fr...
Je me souviens avoir vu un cas de verrouillage optimiste qui ne
fonctionnait pas car la précision du DateTime était supérieure à la
précision côté client (et les dates insérées côté serveur utilisaient
cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
Est-ce qu'il faudrait alors tout basculer en DateTime si l'argument taille
n'est pas un obstacle ?
Je voulais dire que ce qui prime avant tout est la précision nécessaire à l'application (donc tout simplement choisir SMALLDATETIME si la précision est suffisante, DATETIME sinon).
L'auttre commentaire est que j'avais vu il y a bien longtemps (voire au siècle dernier !) quelqu'un avoir un problème sur le verrouillage optimiste à cause d'une trop grande précision dans les données DATETIME (il reste possible de tronquer légèrement les valeurs si le cas osait encore se produire encore de nos jours, je ne veux pas dire que DATETIME n'est pas utile).
En résumé, je pense qu'il faut avant tout voir de quoi a besoin l'application plutôt que de rentrer dans des considérations que je trouve oiseuses (par exemple quelq'un pourrait te dire que sur un processeur 32 bites et datetime étant stocké sur 4 octets, choisir datetime au lieu de smalldatetime qui serait pourtant suffisant te fera gagner de très importantes microsecondes, si, si ! etc...).
-- Patrice
"okpwal" a écrit dans le message de news:
Je me souviens avoir vu un cas de verrouillage optimiste qui ne fonctionnait pas car la précision du DateTime était supérieure à la précision côté client (et les dates insérées côté serveur utilisaient cette précision maxi.).
De toute façon je pense que c'est toujours le besoin qui prime...
Est-ce qu'il faudrait alors tout basculer en DateTime si l'argument taille n'est pas un obstacle ?
-- okpwal la perdrix !
okpwal
> Je voulais dire que ce qui prime avant tout est la précision nécessaire à l'application (donc tout simplement choisir SMALLDATETIME si la précision est suffisante, DATETIME sinon).
L'auttre commentaire est que j'avais vu il y a bien longtemps (voire au siècle dernier !) quelqu'un avoir un problème sur le verrouillage optimiste à cause d'une trop grande précision dans les données DATETIME (il reste possible de tronquer légèrement les valeurs si le cas osait encore se produire encore de nos jours, je ne veux pas dire que DATETIME n'est pas utile).
En résumé, je pense qu'il faut avant tout voir de quoi a besoin l'application plutôt que de rentrer dans des considérations que je trouve oiseuses (par exemple quelq'un pourrait te dire que sur un processeur 32 bites et datetime étant stocké sur 4 octets, choisir datetime au lieu de smalldatetime qui serait pourtant suffisant te fera gagner de très importantes microsecondes, si, si ! etc...).
Je te remercie pour ces éclaircissements. G.
-- okpwal la perdrix !
> Je voulais dire que ce qui prime avant tout est la précision nécessaire à
l'application (donc tout simplement choisir SMALLDATETIME si la précision est
suffisante, DATETIME sinon).
L'auttre commentaire est que j'avais vu il y a bien longtemps (voire au
siècle dernier !) quelqu'un avoir un problème sur le verrouillage optimiste à
cause d'une trop grande précision dans les données DATETIME (il reste
possible de tronquer légèrement les valeurs si le cas osait encore se
produire encore de nos jours, je ne veux pas dire que DATETIME n'est pas
utile).
En résumé, je pense qu'il faut avant tout voir de quoi a besoin l'application
plutôt que de rentrer dans des considérations que je trouve oiseuses (par
exemple quelq'un pourrait te dire que sur un processeur 32 bites et datetime
étant stocké sur 4 octets, choisir datetime au lieu de smalldatetime qui
serait pourtant suffisant te fera gagner de très importantes microsecondes,
si, si ! etc...).
> Je voulais dire que ce qui prime avant tout est la précision nécessaire à l'application (donc tout simplement choisir SMALLDATETIME si la précision est suffisante, DATETIME sinon).
L'auttre commentaire est que j'avais vu il y a bien longtemps (voire au siècle dernier !) quelqu'un avoir un problème sur le verrouillage optimiste à cause d'une trop grande précision dans les données DATETIME (il reste possible de tronquer légèrement les valeurs si le cas osait encore se produire encore de nos jours, je ne veux pas dire que DATETIME n'est pas utile).
En résumé, je pense qu'il faut avant tout voir de quoi a besoin l'application plutôt que de rentrer dans des considérations que je trouve oiseuses (par exemple quelq'un pourrait te dire que sur un processeur 32 bites et datetime étant stocké sur 4 octets, choisir datetime au lieu de smalldatetime qui serait pourtant suffisant te fera gagner de très importantes microsecondes, si, si ! etc...).
