Problème de débutant requête sql

Bonjour,

J'ai une table sql et dans cette table dans la colonne publish_date je souhaiterai insérer un UNIX TIMESTAMP.
L'heure en milliseconde.de a partir de 1970

Est que quelqu'un pourrais m'aider svp ?

Ma table ressemble a ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

CREATE TABLE [dbo].[latest_info]( [id] [int] IDENTITY(1,1) NOT NULL, [type] [varchar](20) NULL, [number] [varchar](255) NULL, [url] [varchar](255) NULL, [title] [varchar](255) NULL, [text] [text] NULL, [publish_date] [varchar](255) , [author] [varchar](50) NULL, [icon] [varchar](50) NULL, PRIMARY KEY CLUSTERED ( [id] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO   ALTER TABLE [dbo].[latest_info] ADD DEFAULT (CURRENT_TIMESTAMP) FOR [publish_date] GO

---

Hello,

Pour stocker un Timestamp UNIX en Millisecondes, votre problème actuel est que votre colonne publish_date est définie comme varchar(255) avec une valeur par défaut CURRENT_TIMESTAMP, ce qui va insérer une date au format texte classique, pas un timestamp UNIX.

Solution recommandée

Pour obtenir un timestamp UNIX en millisecondes, tu dois modifier ta table ainsi :

Code:

---

1 2 3 4 5 6 7 8 9

-- Supprimer d'abord la contrainte DEFAULT existante ALTER TABLE [dbo].[latest_info] DROP CONSTRAINT DF__latest_info__publish_date; -- Le nom peut varier -- Modifier la colonne et ajouter le nouveau DEFAULT ALTER TABLE [dbo].[latest_info] DROP COLUMN [publish_date]; ALTER TABLE [dbo].[latest_info] ADD [publish_date] BIGINT DEFAULT (DATEDIFF_BIG(MILLISECOND, '1970-01-01 00:00:00', GETUTCDATE()));

---

Explications

• BIGINT : nécessaire car les timestamps en millisecondes dépassent la capacité d'un INT (un timestamp actuel fait environ 13 chiffres)
• DATEDIFF_BIG : calcule la différence en millisecondes depuis le 1er janvier 1970 (epoch UNIX)
• GETUTCDATE() : utilise l'heure UTC (recommandé pour les timestamps)

Insertion manuelle

Pour la date actuelle :

Code:

---

1 2 3 4 5

INSERT INTO [dbo].[latest_info] (type, number, url, title, text, publish_date, author, icon) VALUES ('type1', '123', 'http://...', 'Titre', 'Texte', DATEDIFF_BIG(MILLISECOND, '1970-01-01 00:00:00', GETUTCDATE()), 'auteur', 'icon.png');

---

Pour une date spécifique (par exemple le 15 novembre 2025) :

Code:

---

1 2 3 4 5

INSERT INTO [dbo].[latest_info] (type, number, url, title, text, publish_date, author, icon) VALUES ('type1', '123', 'http://...', 'Titre', 'Texte', DATEDIFF_BIG(MILLISECOND, '1970-01-01 00:00:00', '2025-11-15 14:30:00'), 'auteur', 'icon.png');

---

Conversion inverse

Pour relire le timestamp et le convertir en date lisible :

Code:

---

1 2 3 4

SELECT id, title, DATEADD(MILLISECOND, publish_date, '1970-01-01 00:00:00') AS date_lisible FROM [dbo].[latest_info];

---

Merci beaucoup.

Quabnd j'execute la commande j'ai cette erreur :

Code:

---

1 2 3 4

Msg 3728, Niveau 16, État 1, Ligne 3 'DF__latest_info__publish_date' is not a constraint. Msg 3727, Niveau 16, État 0, Ligne 3 Could not drop constraint. See previous errors.

---

Pouriez vous m'aider ?

Trouvez et Modifier la Contrainte DEFAULT !

1. Trouvez le nom de la contrainte

SQL Server génère un nom automatique quand vous utilisez DEFAULT sans le nommer. Voici la requête pour le trouver :

Code:

---

1 2 3 4 5 6 7 8 9 10

SELECT name FROM sys.default_constraints WHERE parent_object_id = OBJECT_ID('dbo.latest_info') AND parent_column_id = ( SELECT column_id FROM sys.columns WHERE object_id = OBJECT_ID('dbo.latest_info') AND name = 'publish_date' );

---

2. Supprimez la contrainte avec le bon nom

Une fois que vous avez le nom exact (par exemple DF__latest_in__publi__123456AB), utilisez-le :

Code:

---

1 2 3

ALTER TABLE [dbo].[latest_info] DROP CONSTRAINT [DF__latest_in__publi__123456AB]; -- Remplacez par le vrai nom

---

3. Solution complète en une seule étape

Voici un script qui fait tout automatiquement :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

-- Déclarer une variable pour stocker le nom de la contrainte DECLARE @ConstraintName NVARCHAR(200); -- Trouver le nom de la contrainte SELECT @ConstraintName = name FROM sys.default_constraints WHERE parent_object_id = OBJECT_ID('dbo.latest_info') AND parent_column_id = ( SELECT column_id FROM sys.columns WHERE object_id = OBJECT_ID('dbo.latest_info') AND name = 'publish_date' ); -- Supprimer la contrainte si elle existe IF @ConstraintName IS NOT NULL BEGIN EXEC('ALTER TABLE [dbo].[latest_info] DROP CONSTRAINT [' + @ConstraintName + ']'); END -- Supprimer et recréer la colonne ALTER TABLE [dbo].[latest_info] DROP COLUMN [publish_date]; ALTER TABLE [dbo].[latest_info] ADD [publish_date] BIGINT DEFAULT (DATEDIFF_BIG(MILLISECOND, '1970-01-01 00:00:00', GETUTCDATE()));

---

Ce script trouvera automatiquement le nom de la contrainte et la supprimera avant de recréer la colonne avec le bon type.

Merci beaucoup !

Vous êtes clair et précis.

La table fonctionne parfaitement.

Je galère par ce que déjà c'est sql server et en plus je connais pas constraints

D'ailleurs a quoi sert il svp.

Car pour créer la table on peu juste mettre une valeur par défaut ? Obligé de passer les constraints ?

C'est quoi une CONSTRAINT ?

Une constraint (contrainte), c'est juste une règle qu'on applique à une colonne. Quand vous écrivez :

Code:

---

1 2 3

ALTER TABLE [dbo].[latest_info] ADD DEFAULT (CURRENT_TIMESTAMP) FOR [publish_date]

---

SQL Server crée automatiquement une constraint DEFAULT en arrière-plan. C'est juste la façon dont SQL Server gère les valeurs par défaut.

Vous n'êtes PAS obligé de les nommer

Vous avez raison, on peut faire simple ! Voici deux approches :

Option 1 : Tout refaire proprement dès le départ

Si vous pouvez recréer votre table, faites comme ça (c'est le plus simple) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

CREATE TABLE [dbo].[latest_info]( [id] [int] IDENTITY(1,1) NOT NULL, [type] varchar NULL, [number] varchar NULL, [url] varchar NULL, [title] varchar NULL, [text] [text] NULL, [publish_date] BIGINT DEFAULT (DATEDIFF_BIG(MILLISECOND, '1970-01-01 00:00:00', GETUTCDATE())), [author] varchar NULL, [icon] varchar NULL, PRIMARY KEY CLUSTERED ([id] ASC) ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO

---

Pas besoin de ALTER TABLE après, tout est défini directement !

Option 2 : Modifier la table existante (si vous avez déjà des données)

Si votre table existe déjà et contient des données, le plus simple :

Code:

---

1 2 3 4 5 6 7

-- Supprimer complètement la colonne (cela supprime automatiquement la constraint) ALTER TABLE [dbo].[latest_info] DROP COLUMN [publish_date]; -- Recréer la colonne avec le bon type et la bonne valeur par défaut ALTER TABLE [dbo].[latest_info] ADD [publish_date] BIGINT DEFAULT (DATEDIFF_BIG(MILLISECOND, '1970-01-01 00:00:00', GETUTCDATE()));

---

C'est tout ! Pas besoin de chercher le nom de la constraint, en supprimant la colonne, tout est supprimé avec.

Pourquoi BIGINT et pas VARCHAR ?

• VARCHAR : stocke du texte, pas pratique pour faire des calculs ou des comparaisons de dates
• BIGINT : stocke un nombre entier, parfait pour les timestamps UNIX en millisecondes

Exemple d'utilisation

Après modification, quand vous insérez sans préciser la date :

Code:

---

1 2 3 4

INSERT INTO [dbo].[latest_info] (type, title, text) VALUES ('news', 'Mon titre', 'Mon texte'); -- publish_date sera automatiquement rempli avec le timestamp actuel

---

Ou si vous voulez mettre une date précise :

Code:

---

1 2 3 4

INSERT INTO [dbo].[latest_info] (type, title, text, publish_date) VALUES ('news', 'Mon titre', 'Mon texte', 1731168000000); -- timestamp en millisecondes

---

C'est plus clair pour vous maintenant ?

Voila la c'est clair !


Merci, je continue de dev l'app android

RESOLU

Citation:

---

Envoyé par fred1599

Pourquoi BIGINT et pas VARCHAR ?

• VARCHAR : stocke du texte, pas pratique pour faire des calculs ou des comparaisons de dates
• BIGINT : stocke un nombre entier, parfait pour les timestamps UNIX en millisecondes

---

Oui, et il y a bien d'autres différences entre BIGINT et varchar

• le varchar et le char sont sensibles à la collation, contrairement aux types numériques comme le BIGINT ;
• le varchar est plus encombrant que le bigint à nombre égal de valeurs distinctes possibles ;
• le varchar nécessite un alignement sur longueur fixe pour les opérations de tri : order by, distinct, group by et partition by ;
• le varchar peut provoquer des désorganisations des pages data et index quand la longueur effective du contenu change.