J'ai une base de données MS Access (assez intolérablement), et de communiquer avec elle par PHP (ODBC).
Il y a un champ DateTime que je dois inclure dans mon instruction INSERT. Ce champ est défini comme « requis » dans Access, ce qui signifie qu'il est en effet, en mesure NULL, et en fait quelques-unes des lignes de la p>
base de données Access sont déjà NULL. Le problème que je vais avoir est simple: Comment insérer NULL dans SQL? Tous les résultats que j'ai trouvé en ligne ont abordé à partir de quelque chose comme Visual Basic ou C #, alors que j'utilise SQL via ODBC dans PHP p>
Je l'ai déjà essayé ce qui suit:. P>
INSERT INTO table_name (datetime_field) VALUES (NULL)
INSERT INTO table_name (datetime_field) VALUES (#NULL#)
INSERT INTO table_name (datetime_field) VALUES ('NULL')
INSERT INTO table_name (datetime_field) VALUES ('#NULL#')
INSERT INTO table_name (datetime_field) VALUES ('')
6 Réponses :
Essayez de le laisser juste vide
Je ne crois pas que cela fonctionnera, il provoque une erreur de syntaxe à la fois à ADO et à la fenêtre de conception de la requête.
Vous pouvez également essayer de laisser la référence au champ entièrement - insert (FLD1, FLD3) Valeurs (VAL1, VAL3)
Oui, tu as raison, j'ai oublié ça. Puisque c'est un champ de date, essayez zéro.
(SIGH) OK, nous avons également eu un problème avec un pilote DB2 ODBC où il devait être configuré d'une certaine manière pour passer des dates sur MS Access DBS. Cela pourrait être quelque chose avec les paramètres du pilote ODBC.
Je ne peux pas le laisser vide car il a une valeur par défaut, donc si je le laisse, ce ne sera pas nul.
Essayez ce qui suit. Cela fonctionne pour moi: Fondamentalement, vous enveloppez la null dans la requête SELECT et laissez SQL déterminer comment le représenter à l'insert. P> - Modifier - p> Ceci devrait également fonctionner: P>
INSERT INTO sometable ( somedate, somethingelse )
values (Null , "foo");
Vous devez avoir une table avec accès, cela ne va pas fonctionner.
Remplacez le SELECT ... avec des valeurs (null, "foo")
@REMOU - Je l'ai essayé de manière native dans MS Access 2007 - et cela fonctionne. C'était une copie droite et une pâte
@David - comme sage, natif dans MS Access 2007, les valeurs (NULL, "FOO") ne fonctionne pas, et il ne fonctionne clairement pas pour l'OP non plus, sur la base de leur premier essai / exemple.
Vous pouvez insérer une sélection à une seule ligne sans un. Si vous vouliez que l'Union deux sélectionne pour l'insert, ce serait une histoire différente.
@CodesLave intéressant, vous êtes juste sur le SELECT NE PAS avoir besoin d'une table dans ce cas, cependant, je ne vois pas pourquoi les valeurs ne fonctionnent pas pour vous. Il est standard SQL et a travaillé sur chaque version de l'accès à ADO et Native car je peux vous rappeler.
Je viens de tester cet insert SQL dans TBLCUSTOMER (nom de famille, créé) ("Fenton", NULL); Dans Access (le champ créé a une valeur par défaut), et cela a fonctionné exactement comme prévu. Je l'ai fait dans la vue SQL QBE, sans aucun mode spécial (par exemple, par défaut SQL 89). Comme @Remou dit, cela a toujours été pris en charge dans Access / Jet / Ace.
@Codeslave: Il y avait évidemment quelque chose de wonky avec votre exemple d'accès. Cela a toujours travaillé dans une installation d'accès par défaut et il n'est pas nécessaire d'utiliser le mode SQL 92 pour le faire fonctionner.
@David. Que puis-je dire? C'était une installation de vanille (toutes les valeurs par défaut), étiquetées à jour et je n'ai jamais échangé des versions ANSI auparavant. Cela a échoué de la même manière que l'OP et ne me laisserait pas insérer à l'aide de "valeurs" du tout. Le retournement entre 89 et 92 et retour à 89 ans a fait fonctionner. J'éprouve que vous vous écrivez, REMOU et HANSUP ont probablement retourné (ou passez à 92 de manière permanente) sur vos installations avant de tester. La seule façon de dire est d'une nouvelle installation; éventuellement sur une station de travail vierge. Je ne peux pas essayer ici ici, mais je vais construire quelque chose le mardi / mercredi pour le prouver.
Je vais également noter que lorsque j'ai construit la requête d'insertion la première fois dans le constructeur de requêtes, il l'a créée exactement comme dans mon premier exemple. Après avoir fait le 89-92-89 Flip, il l'a fait la deuxième façon. Quiconque a un contact sur l'équipe de développement de bureau de MS. Ceci est vraiment unique.
Je n'utilise pas SQL 92 Sauf pour tester les choses à ce sujet! Donc, oui, mon installation a été retournée, mais la prise en charge des inserts sans sélection n'est pas un problème SQL 92 en premier lieu. C'est SQL standard de tourbière qui a été supporté avant que le mode SQL 92 n'existait même pas. Je viens de le tester en A97 et cela a bien fonctionné. Je suppose que vous avez plusieurs versions d'accès installées et finalisées dans une version qui n'avait pas terminé le processus de ré-enregistrement après avoir exécuté l'une des autres versions.
Désolé David, pas de dés. Vanille Installer. Mais le fait que vous ayez commuté auparavant, cela serait compatible avec ce que j'ai vécu. Comme je l'ai dit, je vais l'essayer sur une toute nouvelle machine cette semaine.
C'est tout un hareng rouge alors que l'OP n'utilise pas du tout accès. Nos installations d'accès n'ont donc rien à voir avec son problème.
Je viens de tester sur une machine différente avec une installation A2003 que je connaisse n'a jamais été retournée entre SQL 89 et SQL 92 MODE. L'insert Select-Moins a fonctionné simplement bien. Essayer la même chose sur la même machine dans A2010 (n'ayant jamais le mode SQL renversé) a également fonctionné. Je ne sais pas quelle est la source de votre problème, mais ce n'est pas quelque chose d'inhérent à l'accès ou à Jet / Ace.
Quelles sont les bibliothèques, vous utilisez pour parler à ODBC?
Pourrait-il s'agir d'un problème avec la syntaxe des valeurs null, la bibliothèque l'interprète?
voir, si Cette page aide.
Remarque: je n'ai pas travaillé avec PHP.
J'utilise les composants ODBC en PHP. Cela n'aurait pas d'importance, car je ne fais que passer SQL au pilote ODBC.
Je ne travaille pas dans PHP que souvent, mais y a-t-il peut-être une valeur magique de PHP OFR NULL ou quelque chose? C'est-à-dire que vous passez le mot "null" comme une chaîne dans la déclaration SQL? C'est un long coup ...
Je sais que vous avez déjà compris cela, mais il y a aussi dbnull
Insérer dans les valeurs Table_Name (DateTime_Field) (dbnull.value)
J'ai ce type d'erreur et Essayez ceci.
INSERT INTO table_name (datetime_field) VALUES (DBNull.value)
Tous les autres champs du tableau sont-ils insérés dans l'incrémentation automatique ou sont-ils attribués par défaut? Parce que c'est la seule façon, vous pouvez insérer une seule colonne de données et créer une nouvelle ligne.
Il y a environ 30 colonnes, aucune d'entre elles incrémentation automatique, certaines d'entre elles ont des valeurs par défaut, mais toutes sont dans la requête elle-même.
Ah OK, vous venez de pair l'exemple vers une seule colonne? Avez-vous essayé de mettre à jour une ligne et de définir le champ sur NULL pour voir?
Je suis d'accord avec Paul Sasik, j'ai essayé une requête dans l'accès à la fenêtre ADO et de la requête, et l'accès était parfaitement heureux avec NULL.
Ouvrez la base de données dans l'accès et essayez votre première instruction Insert en tant que nouvelle requête ... laissant ODBC et PHP hors de l'image temporairement. Basé sur tout ce que vous avez dit, je ne vois pas pourquoi l'accès Le moteur de base de données rejeterait votre premier exemple d'instruction d'échantillon.
Le premier insert fonctionnera simplement bien dans l'accès, en supposant qu'il n'y ait aucun champ obligatoire sans valeurs par défaut. Si cela ne fonctionne pas, il y a quelque chose d'interférant entre PHP et Jet / Ace.
@Hansup et @David - J'ai dupliqué le même phénomène Nativement en 2007 (pas de PHP) moi-même. Le premier échoue.
@Codeslave: votre dernier commentaire devrait être supprimé maintenant, non?
@David J'ai expérimenté le même phénomène que l'OP, alors IMHO Le commentaire est toujours valide. Tout ce qui est changé est que j'ai maintenant "correction". Vous, Paul, Remou et Hansup sont tous corrects. Cela devrait fonctionner, mais cela ne fait pas pour l'Op et ce n'est pas pour moi avant d'avoir renversé les normes ANSI SQL en arrière.
@Codeslave: vous êtes très confus. Le mode SQL n'est pas un problème Jet / Ace, mais un problème d'accès. Jet / Ace ne sait rien du tout sur le mode SQL 89 ou SQL 92 - c'est pourquoi quel mode que vous utilisez est contrôlé non par la version Jet / Ace, mais par l'interface que vous utilisez pour interagir avec Jet / Ace. Mais ce n'est pas un problème de mode SQL, de toute façon, car le SQL correspondant fonctionne dans les versions d'accès qui prédisent l'introduction du mode SQL 92.
@David, soit l'OP et moi mentons ou il y a quelque chose qui se passe ici. Croyez ce que vous aimez. Je vous dis que j'ai eu le même genre de résultats que l'OP. J'ai renversé le SQL de 89 à 92, puis cela a fonctionné comme prévu. Je le retournai à 89 ans et je travaillais toujours comme prévu. Cela n'a aucun sens, il n'aurait pas dû être réparé quoi que ce soit, mais c'est ce qui s'est passé. Et étant donné que l'OP semble avoir essayé mon tour, et maintenant, il semble y travailler comme par magie pour eux (même s'ils disent que cela n'a pas immédiatement), cela me rend plus méfiant que j'ai raison.
L'OP n'utilise pas l'accès. Le mode SQL est un paramètre d'accès, pas un paramètre Jet / Ace. Donc, il n'est pas possible que votre problème et que la puissance ait la même source.