Well, I have rather odd exception when I try to insert new value. Please, see attached files for further investigation.
So, I use:
SQL Server 2012
VS 2012 Update 2
EF6 Alpha 3 Code First
The problem is I'm trying to insert new value into simple table called dbo.Worker2 (see "Worker2 Table" image file) which consists of 2 columns: TableNumber and Name. The TableNumber column is primary key of integer data type (see "Primary Key column properties" image file). I have installed the latest EF6 alpha3 and trying to insert new value (see "VB.NET Code" image file). However, exception is thrown: "Cannot insert NULL the value NULL into column 'TableNumber', table Bonus.dbo.Worker2'; column does not allow nulls. INSERT fails." (see "VS Exception" image file).
Then I have decided to see what T-SQL query EF sends to SQL Server with SQL Server Profiler and was surprised that no TableNumber was sent by EF (see "Profiler Queries" image file).
Is it bug or I have missed something?
By the looks of it you need to set your Worker2 Primary Key property as non-database generated.
something like:
<Key, DatabaseGenerated(DatabaseGeneratedOption.None)>
Public Property TableNumber As Integer
I think Primary Key is not set to identity.
Related
I have migrated an AnyDAC app to FireDAC and I can't get to work its Autoinc fields.
The ID field (primary key) has been defined on Postgre SQL as default to nextval('llistapanelspuzzle_id_seq'::regclass), BIGSERIAL, so the server automatically sets its values.
The column was recognized by AnyDAC as an TAutoincField and worked correctly, but when I now open that table on FireDAC it fails saying that the field found is a TLargeIntField. I change the persistent field to a TLargeIntField, but now when inserting records on Delphi, I don't get the new values from the server, it leaves the dataset with a 0 value, and when I add a second record it raises a Key Violation (two records with a 0 value on its primary key).
Do you know how to define AutoInc fields on FireDAC - PostgreSQL, when they are being recognized as LargeInt fields ?.
Update: I have added ID to the UpdateOptions.AutoIncFields, but it doesn't seem to have changed anything.
Thank you.
Looks like you have to activate the ExtendedMetada flag on the FDConnection in order for FireDAC to recognize automatically the PostgreSQL Autoinc columns.
Now it works correctly.
I am migrating data from MSSQL.
I created the database in PostgreSQL via npgsql generated migration. I moved the data across and now when the code tries to insert a value I am getting
'duplicate key value violates unique constraint'
The npgsql tries to insert a column with Id 1..how ever the table already has Id over a thousand.
Npgsql.EntityFrameworkCore.PostgreSQL is 2.2.3 (latest)
In my context builder, I have
modelBuilder.ForNpgsqlUseIdentityColumns();
In which direction should I dig to resolve such an issue?
The code runs fine if the database is empty and doesn't have any imported data
Thank you
The values inserted during the migration contained the primary key value, so the sequence behind the column wasn't incremented and is kept at 1. A normal insert - without specifying the PK value - calls the sequence, get the 1, which already exists in the table.
To fix it, you can bump the sequence to the current max value.
SELECT setval(
pg_get_serial_sequence('myschema.mytable','mycolumn'),
max(mycolumn))
FROM myschema.mytable;
If you already know the sequence name, you can shorten it to
SELECT setval('my_sequence_name', max(mycolumn))
FROM myschema.mytable;
When I add a column in the database, under what conditions do I need to update my EDMX?
To elaborate:
I know if I add a non-nullable field, I need to update the model if I want to write to the database. What if just I want to read?
What if it's a nullable field? Can I both read and write?
What if I were to change the primary key to the new column but the edmx still has the old column as primary?
1) If you want to port an old database, you need to make sure that every table in your database must have a primary key. This is the only requirement for creating the EDMX.
2) If you've added a column in a table at database side, and have not updated edmx, then you'll simply not be able to use that column though EntityFramework.
If you create a non nullable column with no default value, the insert operation will fail with exception "Cannot insert null into column , statement terminated". And the you'll not be able to read values of that column using entityframeowrk, unless you update the edmx.
3) If you've changed the primary key of any table at database side, and if the edmx is not aware of that, your application might create a runtime exception when performing operations with that table.
Remember, Entity Framework creates SQL queries depending upon its knowledge of database(which is defined in EDMX). So if EDMX is incorrect, the resulting SQL queries so generated might lead to problems at runtime.
I am using a Firebird 2.1 database together with VS2010 (.NET 4.0) and am trying to get it to work properly with the entity framework.
The problem is, that when I generate an entity from a database table, the framework detects all columns to be part of the primary key. The table is very simple with two integer columns, one of them being set as primary key.
I even have "#PK_GEN#" set as comment of the primary key column.
In the EF-Editor I cannot modify the primary key property of the store object, and since I will have to deal with nullable columns, that is a problem. I can edit the XML code of the model file, but the changes are non-persistent when updating the model, so that is a show-stopper.
Since I only read about similar problems concerning views not tables, I am obviously doing something wrong, but I can't figure it out.
edit: By the way, I just tested the behavior with VS 2012 and it remains unchanged.
Here's the CREATE script. Since I'm new to Firebird, there might me something wrong here as well, but I really don't think so.
CREATE GENERATOR GEN_TESTTABLE_ID;
CREATE TABLE TESTTABLE (
TESTTABLE_ID INTEGER NOT NULL,
VALUE INTEGER
);
ALTER TABLE TESTTABLE ADD CONSTRAINT PK_TESTTABLE PRIMARY KEY (TESTTABLE_ID);
COMMENT ON COLUMN TESTTABLE.TESTTABLE_ID IS '#PK_GEN#';
SET TERM ^ ;
CREATE OR ALTER TRIGGER TESTTABLE_BI_GEN_ID FOR TESTTABLE
ACTIVE BEFORE INSERT POSITION 0
AS
begin
if ((new.testtable_id is null) or (new.testtable_id = 0) ) then
begin
new.testtable_id = gen_id(gen_testtable_id, 1);
end
end
^
SET TERM ; ^
Problem is, that Firebird 2.1 contains a bug, that results in this. Generate the model using Firebird 2.5 and you'll be fine.
Some references here, here, here.
I have executed the following create statement using SQLWorkbench at my target postgresql database:
CREATE TABLE Config (
id serial PRIMARY KEY,
pub_ip_range_low varchar(100),
pub_ip_range_high varchar(100)
);
Right after table creation I request the table content by typing 'select * from config;' and see that table could be retrieved. Nevertheless, my java program that uses JDBC type 4 driver cannot access the table when I issue the same select statement in it. An exception is thrown when the program tries to access it which says says "Undefined relation" for the config table.
My questions are:
Why sqlworkbench where I had previously run the create statement recognizes the table while my java program cannot find it?
Where does the postgressql DBMS puts the tables I created? I don't see them neither in public nor in information schema.
NOTE:
I checked target postgres database and cannot see the table Config anywhere although SQL workbench can query it. Then I opened another SQL workbench instance and noticed that the table cannot be queried (i.e. not found). So, my conclusion is that PostgreSQL puts the table I created in the first running SQLBench instance into some location that is bound to that session. Another SQL Workbench instance or my java program is not bound to session, so cannot query the previously created table config.
The only "bloody location" that is session-local in PostgreSQL is the schema pg_temp, in other words: temporary tables. But your CREATE command does not display the keyword TEMP[ORARY]. Of course, as long as the transaction is not commited, nobody sees anything outside the transaction.
It's more likely you are seeing a switcheroo of hosts / databases / ports / or the schema search_path. A mixup with the mixed-case table name is a hot candidate, too. If you don't double-quote "Config", the table ends up all lower case in the system, so: config. If you later double quote the name, it won't match. The manual has the details.
Maybe the create failed on the extra trailing comma?
CREATE TABLE config (
id serial PRIMARY KEY,
pub_ip_range_low varchar(100),
pub_ip_range_high varchar(100) -- >> ,
);