Ich habe ein CREATE TABLE Skript. Wenn ich es über die -Befehlszeile ausführe, erstellt es keine nullfähigen Spalten. Wenn ich es manuell über SQL Server Query Browser ausführen, tut es. Was vermisse ich?Warum behandelt SQL Server dieselbe SQL anders?
über die Kommandozeile
ich versucht ist Lehre 2 Schema-Kommandozeilen-Tool zu verwenden, um mein Schema in SQL Server 2014 (1) zu erstellen.
Hier ist die SQL ist es aus meiner Entität Anmerkungen erstellt (2) (beachten Sie, address_2 ist nullable) (der Abstand Pfeil und sind von mir):
# dump the SQL Doctrine will use
vendor/bin/doctrine-module orm:schema-tool:create --dump-sql
CREATE TABLE company (
id INT IDENTITY NOT NULL,
address_1 NVARCHAR(255) NOT NULL,
address_2 NVARCHAR(255), <-- it should be optional
city NVARCHAR(31) NOT NULL,
email NVARCHAR(255),
name NVARCHAR(255) NOT NULL,
phone NVARCHAR(12),
state NVARCHAR(2) NOT NULL,
zip NVARCHAR(5) NOT NULL,
PRIMARY KEY (id)
);
# execute the command
vendor/bin/doctrine-module orm:schema-tool:create
Nach SQL Server Profiler, erhält SQL Server die folgende Befehle (beachten Sie, sollte address_2 noch nullable sein) (der Abstand Pfeil und sind von mir):
set textsize 20971520
go
set textsize 2147483647
set quoted_identifier on
go
SET ANSI_WARNINGS ON
go
SET ANSI_PADDING ON
go
SET ANSI_NULLS ON
go
SET QUOTED_IDENTIFIER ON
go
SET CONCAT_NULL_YIELDS_NULL ON
go
CREATE TABLE company (
id INT IDENTITY NOT NULL,
address_1 NVARCHAR(255) NOT NULL,
address_2 NVARCHAR(255), <-- it should be optional
city NVARCHAR(31) NOT NULL,
email NVARCHAR(255),
name NVARCHAR(255) NOT NULL,
phone NVARCHAR(12),
state NVARCHAR(2) NOT NULL,
zip NVARCHAR(5) NOT NULL,
PRIMARY KEY (id)
)
go
jedoch, wenn Sie die erstellte Tabelle inspizieren, address_2 ist NOT NULL.
Hier ist ein Screenshot der Tabelle Browser sowie die Ausgabe von SQL Server's equivalent to MySQL's SHOW CREATE TABLE (der Abstand Pfeil und ist von mir):
Table created via command line
USE [mydatabase]
GO
/****** Object: Table [dbo].[company] Script Date: 11/11/2016 9:47:03 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[company](
[id] [int] IDENTITY(1,1) NOT NULL,
[address_1] [nvarchar](255) NOT NULL,
[address_2] [nvarchar](255) NOT NULL, <-- it's not optional!
[city] [nvarchar](31) NOT NULL,
[email] [nvarchar](255) NOT NULL,
[name] [nvarchar](255) NOT NULL,
[phone] [nvarchar](12) NOT NULL,
[state] [nvarchar](2) NOT NULL,
[zip] [nvarchar](5) NOT 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) ON [PRIMARY]
) ON [PRIMARY]
GO
über den Query Browser
Jetzt, Hier kommt der lustige Teil.
Wenn Sie die genau gleichen Befehle ausführen, die SQL Server (nach dem SQL Server Profiler) in dem SQL Server Query Browser empfangen wird (der Abstand Pfeil und ist von mir):
set textsize 20971520
go
set textsize 2147483647
set quoted_identifier on
go
SET ANSI_WARNINGS ON
go
SET ANSI_PADDING ON
go
SET ANSI_NULLS ON
go
SET QUOTED_IDENTIFIER ON
go
SET CONCAT_NULL_YIELDS_NULL ON
go
CREATE TABLE company (
id INT IDENTITY NOT NULL,
address_1 NVARCHAR(255) NOT NULL,
address_2 NVARCHAR(255), <-- it should be optional
city NVARCHAR(31) NOT NULL,
email NVARCHAR(255),
name NVARCHAR(255) NOT NULL,
phone NVARCHAR(12),
state NVARCHAR(2) NOT NULL,
zip NVARCHAR(5) NOT NULL,
PRIMARY KEY (id)
)
go
Die address_2 Feld ist NULL:
Table created via query browser
USE [mydatabase]
GO
/****** Object: Table [dbo].[company] Script Date: 11/11/2016 9:49:41 AM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[company](
[id] [int] IDENTITY(1,1) NOT NULL,
[address_1] [nvarchar](255) NOT NULL,
[address_2] [nvarchar](255) NULL, <-- it's optional!
[city] [nvarchar](31) NOT NULL,
[email] [nvarchar](255) NULL,
[name] [nvarchar](255) NOT NULL,
[phone] [nvarchar](12) NULL,
[state] [nvarchar](2) NOT NULL,
[zip] [nvarchar](5) NOT 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) ON [PRIMARY]
) ON [PRIMARY]
GO
Fazit
Was in der Welt ist los? Wie kann das gleiche SQL-Skript produzieren verschiedene Ergebnisse?
Ich habe im Internet nach Hilfe gesucht, aber ich kann keine Erklärung oder Lösung für das Problem finden. Jede Hilfe würde sehr geschätzt werden!
In meinem Kopf:
- Die
SETFlaggen sollten keine Rolle spielen, da die Abfrage in dem SQL Server Query Browser mit ihnen arbeitet. Außerdem habe ich nach ihnen gesucht, und keiner von ihnen scheint das Verhalten von T-SQL gegenüber optionalen Spalten zu ändern. - Die Hoops, die ich durchsprang, um Doctrine mit SQL Server von einem * nix-Rechner zu verbinden, sollten keine Rolle spielen (1), da die Befehle, die SQL Server erreichen (wie vom SQL Server Profiler gezeigt), im Query Browser funktionieren.
Fußnoten
- Ich verbinde Lehre zu SQL Server von einem CentOS Maschine. Ich verwende FreeTDS, um eine Verbindung zum SQL Server herzustellen, und ich verwende einen DBlib Doctrine Driver von Drittanbietern. Ich weiß, das ist gewunden, haha.
- Ich habe die Entität nicht eingeschlossen, weil ich nicht sicher bin, dass es helfen wird. Das von Doctrine generierte SQL ist korrekt.
['SET ANSI_NULL_DFLT_ON'] (https://msdn.microsoft.com/library/ms187375). Und jetzt weißt du, warum du immer explizit sein solltest. –
Spot auf Bemerkung von Jeroen :). Kleine Frage: Wenn Sie "SQL Server Query Browser" erwähnen, meinen Sie "SQL Server Management Studio"? –
@JeroenMostert du bist mein Held! Ich konnte die erstellte SQL Doctrine nicht ändern. Aber ich habe die globale Option für die Datenbank (Rechtsklick-Datenbank> Eigenschaften> Optionen> ANSI NULL Default auf true gesetzt), und es wurde behoben! Lektion gelernt! Können Sie Ihr _comment_ stattdessen als _answer_ hinzufügen, damit ich es akzeptieren kann? – Jack