Dans Google BigQuery, j'ai un champ d'horodatage qui a l'année 20195. Ceci est bien sûr, provoquant des erreurs car il est en dehors de la gamme standard SQL TimeStamp. Cependant, je ne peux pas mettre à jour ces enregistrements ou supprimer cet enregistrement comme erreur, même en utilisant Safe_cast. Par exemple, j'ai essayé:
UPDATE [table] SET DateField = SAFE_CAST('2019-01-01 00:00:00 UTC' AS TIMESTAMP)...
3 Réponses :
Vous pouvez utiliser le coffre-fort préfixe pour retourner null à la place:
Merci Gordon, je peux utiliser en toute sécurité. lire, mais il met à jour ou supprimer la ligne qui est délicate,
Vous pouvez convertir en microsecondes (qui n'entraîne pas une vérification des limites), puis essayez de reconvertir la ligne, supprimant la ligne si la conversion sécurisée entraîne NULL:
UPDATE dataset.table SET ts = SAFE.TIMESTAMP_MICROS(UNIX_MICROS(ts)) WHERE true
Merci Elliott, mais je reçois la même erreur: impossible de retourner une valeur chronométrée non valide de ...
Avec les deux requêtes? Avez-vous plus d'une colonne d'horodatage?
Oui avec les deux requêtes, il y a quelques colonnes de timbres de plus, mais ce n'est pas un problème, j'ai vérifié et c'est juste cette 1 colonne avec un mauvais horodatage
Si vous souhaitez réparer les valeurs mauvaises à l'aide de le Mettre à jour , vous devez l'appliquer dans toute la table, en utilisant un conditionnel. La réponse d'Elliot est correcte mais je ne peux pas ne pas pouvoir commenter ou uppoter, donc je vais élaborer légèrement et répondre à cette question: où vrais est le secret Sauce, qui n'est pas évidente de la réponse d'Elliot. Si vous essayez de faire où id = 1234 ou quoi que ce soit continuera de donner la même erreur. sûre.date est un moyen concis de vérifier les dates valides et retournera null si elles sont invalides, mais votre champ peut être nullable, c'est pourquoi j'ai ajouté le chèque null .
S'il vous plaît montrer la requête où vous avez le problème.