Mimic-code: Impossible de déterminer l'erreur inconnue du fichier chartevents.csv

Avez-vous vérifié l'intégrité de votre copie de chartevents.csv à l'aide des fichiers de somme de contrôle fournis sur la page de téléchargement du projet ? Il a peut-être été corrompu lors du téléchargement ou de la décompression.

Oui, j'ai utilisé la commande md5 checksum_md5_zipped.txt et tout est OK avec toutes les tables...

J'ai également essayé avec des données compressées et exécuté postgres_load_data script_7zip. Dans ce cas, j'obtiens : une nouvelle ligne sans guillemets trouvée dans les données. Conseils : utilisez le champ CSV entre guillemets pour représenter la nouvelle ligne.

J'ai également vérifié md5 checksum_md5_unzipped.txt et tout va bien.

Il semble qu'il y ait un décalage entre le script que vous exécutez et les données dont vous disposez. je m'assurerais :

1. Tous les fichiers sont dans le même répertoire
2. Tous les fichiers ont la même extension de fichier ; par exemple, ils sont tous .csv.gz
3. Vous exécutez le fichier postgres_load_data_7zip.sql (i) à partir du même dossier ou (ii) après avoir configuré mimic_data_dir pour pointer vers le répertoire de données.

Après cela, il est vraiment difficile de déboguer à distance sans plus d'informations comme une capture d'écran de la configuration de votre dossier, les informations de votre système, les commandes exactes que vous avez exécutées et le message d'erreur exact.

Bonjour,

Merci pour votre réponse.

1. Tous les fichiers sont dans le même répertoire
2. Tous les fichiers ont la même extension de fichier csv
3. J'exécute le fichier posgres_load_data.sql après avoir configuré mimic_data_dir pour pointer vers le répertoire de données.
   Voici mes commandes exactes et l'erreur que j'ai eue.
   
   
   

Super c'est très utile, merci pour les informations supplémentaires. Je pense que c'est aussi simple que le fichier n'étant pas dans le dossier. Pouvez-vous vérifier que votre dossier C:/Users/Lejla/Desktop/MIMICIII contient le fichier CHARTEVENTS.csv ?

Il se peut que vous ayez essayé d'extraire tous les fichiers compressés, mais cela a échoué pour les événements de charte et vous n'avez donc qu'un fichier .csv.gz (les raisons peuvent être parce que le fichier extrait fait 33 Go et que vous manquez d'espace, ou que votre le système de fichiers est FAT32 (!), ou qui sait). Dans ce cas, vous pouvez modifier le script de chargement pour le charger directement à partir de .csv.gz . Vous pouvez le faire en remplaçant :

\copy CHARTEVENTS from 'CHARTEVENTS.csv' delimiter ',' csv header NULL ''

avec

\copy CHARTEVENTS from PROGRAM '7z e -so CHARTEVENTS.csv.gz' delimiter ',' csv header NULL ''

Merci beaucoup pour la réponse. J'ai essayé cette fois de travailler avec un fichier zip et d'exécuter un script pour celui-ci. Cette fois j'en ai d'autres

message... Peut-être que cela aidera.

Cela vous dérange-t-il d'afficher le contenu du répertoire ?

ça ne me dérange pas.voici le contenu de mon dossier

D'accord, le could not stat file "CHARTEVENTS.csv": Unknown error est en fait un bogue dans PostgreSQL 11. Sous le capot, il appelle fstat() pour s'assurer que le fichier n'est pas un répertoire, et malheureusement fstat() est un programme 32 bits qui ne peut pas gérer de gros fichiers comme chartevents. J'ai testé la version sur Windows avec PostgreSQL 10.5 et je n'ai pas eu cette erreur donc je pense que c'est assez nouveau.

La meilleure solution consiste à conserver les fichiers compressés (c'est-à-dire à les conserver sous forme .csv.gz fichiers https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

La version brève de ci-dessus est que vous conservez les fichiers .csv.gz , vous ajoutez le binaire 7zip à votre chemin d'environnement Windows, puis vous appelez le fichier postgres_load_data_7zip.sql pour charger les données. Vous pouvez utiliser le fichier postgres_checks.sql après tout pour vous assurer que vous avez correctement chargé toutes les données.

edit : pour votre erreur ultérieure, lorsque vous utilisez cette approche 7zip, je ne sais pas pourquoi elle ne se charge pas. Essayez de retélécharger uniquement le fichier ADMISSIONS.csv.gz et voyez s'il vous renvoie toujours la même erreur. Peut-être qu'il y a une nouvelle version de 7zip qui m'oblige à mettre à jour le script ou quelque chose comme ça !

Bonjour,
Merci pour l'explication détaillée. J'ai installé PostgreSQL 10.5 et maintenant le processus est en cours d'exécution. Je pense qu'il faudra beaucoup de temps pour charger toutes les tables mais je n'obtiens plus "Erreur inconnue". Merci beaucoup pour toute l'aide.

Super!

D'accord, le could not stat file "CHARTEVENTS.csv": Unknown error est en fait un bogue dans PostgreSQL 11. Sous le capot, il appelle fstat() pour s'assurer que le fichier n'est pas un répertoire, et malheureusement fstat() est un programme 32 bits qui ne peut pas gérer de gros fichiers comme chartevents. J'ai testé la version sur Windows avec PostgreSQL 10.5 et je n'ai pas eu cette erreur donc je pense que c'est assez nouveau.

La meilleure solution consiste à conserver les fichiers compressés (c'est-à-dire à les conserver sous forme .csv.gz fichiers https://mimic.physionet.org/tutorials/install-mimic-locally-windows/

La version brève de ci-dessus est que vous conservez les fichiers .csv.gz , vous ajoutez le binaire 7zip à votre chemin d'environnement Windows, puis vous appelez le fichier postgres_load_data_7zip.sql pour charger les données. Vous pouvez utiliser le fichier postgres_checks.sql après tout pour vous assurer que vous avez correctement chargé toutes les données.

edit : pour votre erreur ultérieure, lorsque vous utilisez cette approche 7zip, je ne sais pas pourquoi elle ne se charge pas. Essayez de retélécharger uniquement le fichier ADMISSIONS.csv.gz et voyez s'il vous renvoie toujours la même erreur. Peut-être qu'il y a une nouvelle version de 7zip qui m'oblige à mettre à jour le script ou quelque chose comme ça !

L'utilisation de PostgreSQL 10.11 m'a aidé... merci

Super c'est très utile, merci pour les informations supplémentaires. Je pense que c'est aussi simple que le fichier n'étant pas dans le dossier. Pouvez-vous vérifier que votre dossier C:/Users/Lejla/Desktop/MIMICIII contient le fichier CHARTEVENTS.csv ?

Il se peut que vous ayez essayé d'extraire tous les fichiers compressés, mais cela a échoué pour les événements de charte et vous n'avez donc qu'un fichier .csv.gz (les raisons peuvent être parce que le fichier extrait fait 33 Go et que vous manquez d'espace, ou que votre le système de fichiers est FAT32 (!), ou qui sait). Dans ce cas, vous pouvez modifier le script de chargement pour le charger directement à partir de .csv.gz . Vous pouvez le faire en remplaçant :

\copy CHARTEVENTS from 'CHARTEVENTS.csv' delimiter ',' csv header NULL ''

avec

\copy CHARTEVENTS from PROGRAM '7z e -so CHARTEVENTS.csv.gz' delimiter ',' csv header NULL ''

Merci, cela a fonctionné pour moi :
\copy my_table_name du programme 'cmd /c type input_data.csv' delimiter ',' en-tête csv ;
input_data.csv comme une taille de 11 Go.

Le problème avec "Impossible de copier des fichiers volumineux" est en place pour les versions 11 et 12. Mais pour 10 c'est ok. Comment le remplacer sans compresser les fichiers de données, mais peut-être pour insérer/échanger certains fichiers du programme Postgresql de v.10 à v 11 et 12 ?
Solution de contournement:
copiez t(c,d) du programme 'cmd /c "type x:\pathto\file.txt"' avec (format text);
-est assez lent pour mes besoins. J'ai besoin de la vitesse de la commande de copie par défaut

Vous pouvez envisager d'utiliser d'autres outils de ligne de commande pour diviser le fichier en plusieurs fichiers, puis charger les fichiers individuels un par un. Sur les systèmes Unix, cela peut être fait en utilisant split et vous pouvez installer les coreutils GNU pour Windows pour l'utiliser.

Je pense avoir rencontré le même problème que vous, mais j'utilise la toute nouvelle version 12. Existe-t-il un moyen de le résoudre ? Utiliser des fichiers compressés ?

Oui, si je me souviens bien les fichiers compressés font < 4 Go et vous évitez cette erreur en utilisant les scripts de chargement compressés (7z ou gzip).

OK, je vais essayer cette méthode maintenant, merci beaucoup pour votre réponse

Alors, pas de solution de contournement SANS utiliser de compression ou de fractionnement du tout ? Utilisation de la version 10 de la commande COPY de Postgresql pour le moteur 11, 12 ?
Comme je l'ai mentionné:
J'ai besoin de la vitesse de la commande Copier par défaut mais pour les gros fichiers + la version 12
et c'est vital pour mes besoins.

Eh bien, PostgreSQL est open source, vous pouvez donc essayer de contribuer vous-même à un correctif :)

Voici la discussion pertinente : https://www.postgresql.org/message-id/20181104000405.GA1743%40paquier.xyz

Sinon, vous avez les trois solutions de contournement proposées dans ce fil (changer de version, utiliser des fichiers compressés, diviser le fichier en plusieurs parties). Je suis sûr qu'il existe d'autres solutions de contournement aussi.

N'est-il pas évident de migrer la partie fonctionnelle du code des fonctionnalités de la version 10 de COPY vers la version 11 et 12 ? Ou c'est tellement codé en dur, que ça cause un crash pour tous ? :)

@ghYura il s'agit d'une ressource gérée par la communauté, donc si vous avez des suggestions pour améliorer la base de code, je vous suggère de faire une demande d'extraction.

J'obtenais l'erreur lors du chargement des CSV dans les tables des versions 12.X et 13.X, mais cela fonctionne comme un charme dans la version PostgreSQL 10.15. Merci à tous pour l'aide :)