I tried rebuilding but it seems that the edmx file doesn't update itself with the changes I made. Any suggestions besides removing the edmx and remaking it?
If you are using Entity Framework 4.0 you can just right-click the white-space in the designer, choose 'Update Model from Database' and hit Finish. This will refresh all tables.
You can add the field manually. It's not so hard, especially if it's a scalar.
Make sure your existing model is checked in in case you have to roll back!
Note the name of some other scalar column in the table, preferably one with a unique name and the same type.
Right click model, "Open With", XML Editor.
Search for the other field.
Add the new field everywhere the other field pops up. There will be at least three different places to change. But note that the field may already be in the SSDL/storage schema, which would be why it didn't add in the first place.
Look at the Errors pane to make sure you haven't messed up the XML validity.
Save and compile.
Now you can edit the new field in the GUI by re-opening the model, if need be.
Related
I have a number of integration tests which access the DB directly - create test prerequisite objects - performs the tests and then cleans up afterwards - however I wonted to try out the same approach in-memory.
I have just used Effort in my project and it works very easily. However I've hit a problem that I have been trying - but unable to solve.
One of the tables that I need filled up with dummy data - as a test prerequisite - contains a computed column (nvarchar, not null). For the scope of the test I really don't care about that column's value - but even if I try to insert dummy data, my data is ignored and then I get hit with an error:
"Column 'x' cannot be null. Error code: GenericError"
In my tests I am using the same edmx file as is used by the actual code. This prevents me from constantly updating the edmx copy.
Is there a way in which I can force the test to update the edmx (at runtime) so that column is a nullable non-computed column? [overriding OnModelCreating] or is there way to insert a default value (anything goes for this column) to stop this error? [overriding SaveChanges]
I have currently tried the following:
Attaching the objects using .Attach() instead of .Add()
Setting the EntityState to Unchanged after adding
Forcing the value through Entry.OriginalValues [this values since entity is in Added state]
Edit:
I have tried overriding the OnModelCreating method, but to no avail since this is DB-First.
modelBuilder.Entity<Entity_Name>().Property(p => p.x).IsOptional().HasDatabaseGeneratedOption(System.ComponentModel.DataAnnotations.Schema.DatabaseGeneratedOption.None);
Open your EDMX file in XML editor, find your entity under the StorageModels,
and add to the column definition StoreGeneratedPattern="Computed".
But if you update or delete and add that table you will loose this modification. Actually you can write console app that will update you edmx file and add StoreGeneratedPattern="Computed" where needed and you can add those app to prebuild events in studio.
The reason of the problem was a bug in the Effort database. When the computed column is based on non-nullable columns, the computed column would also automatically become non-nullable. Therefor, the Effort database was expecting a non-null value. With the latest update the problem is resolved. You have to set the global EntityFrameworkEffortManager.UseDefaultForNotNullable flag as true.
See the issue on github
I haven't had this problem until I first tried to manually add data to a database since my upgrade to WebMatrix 3, so I don't know if this is a bug or some kind of fault prevention.
I have defined a very simple table with the primary key as int and set it to not allow nulls, and be of the type IsIdentity so that the int value will automatically increment, as needed.
A pic of that is shown here:
Okay, seems simple enough, but when I try to manually add data to the table, it, as it should, does NOT allow me to modify the primary key value in any way (because it is automatic).
All I do is put in a couple of string values to the type and location columns and it tells me that it couldn't commit changes to the database because of the invalid value in the primary key field (it acts as though it is gonna try to throw NULL in as the value, but this should be overridden when it automatically adds the row. The user-interface does not allow me to control or edit this value in anyway).
A pic of this is shown here:
What is this? Some kind of bug? Is it a new rule that WebMatrix does not allow a developer to add values to the database manually? Do I have to write a query every time I want to add something to the database? Am I in the Twilight Zone? (Okay, sorry about the last one...)
Also, I've noticed that if I don't have IsIdentity set, I can edit the field, put a PERFECTLY VALID integer therein, and it still errors the same way, so I use ESC to backup my changes, then hit refresh, only to find that it did, indeed, add the row anyway :/ . So, this interface seems kind of buggy to begin with. In my scenario above (using IsIdentity), it DOES NOT add the row anyway, unfortunately.
--------------------UPDATE--------------------------
I just recently downloaded a WebMatrix update, and it appears that they have fixed this! Yay! (till now I was just querying generic INSERT INTO statements and editing them manually from there).
I think the SQL CE tooling with WM3 is broken, suggest you look at other tools for editing data - I can recommend the standalone SQL Server Compact Toolbox (disclosure: I am the author)
I have a emdx file with update-able views. I made these views by following an example here where I delete the name and the type and leave just dbo:schema, however, every time I pick "Update Model from Database" these views and the entire definition including associations and such, get removed from the file.
To solve this problem, I end up doing a manual merge with the previous version, however, this is a really long and painful process.
Anyone know what I'm doing wrong?
Example of my declared update-able view:
<EntitySet Name="vw_MeterEmisHist" EntityType="Model.Store.vw_MeterEmisHist" Schema="dbo" />
I have had the same this happen when adding node to allow for mapping stored procedures to entities. The reason for this is that the XML formatted EDMX file is always completely auto generated when the model is updated (or created) from the database.
The easiest work around that I have found is to keep a text file within my solution with the changes that I have made so that they can be easily replaced. To speed things up, its possible to create a find/replace macro within Visual Studio to automate the process.
If anyone ever gets really bored, that sort of functionality would make a great add-in. (Or a great fix in VS. MS, are you listening?)
I have a SQL database where one of my fields 'Status' has one of 10 entries in it (not from a dropdown list). I let some people have access to the data through an Access database, they can add and modify entries.
My question is, in Access, how can I make it so that the 'Status' field is a drop-down list from which the users can choose from (the 10 entries which are already in the SQL database)? It would be easier for them and also mean that mistakes cannot be made.
Many thanks
Scott
The usual way to do this is to use a combo box on a form with the row source taken from the look-up table and the bound column set to the field (column) of the table to be updated.
In Access you can add lookup information to a column. That will automatically display a dropdown list.
Step 1: Start the lookup wizard:
Step 2: After the wizard, the lookup settings should look like this:
Step 3: When your users open a table, they should see the dropdown box:
In addition to the solution described by Andomar you must not use another table as the source for your lookup. You can also provide the lookup-values in a list, which is hardcoded in the table-definition. This is fine for simple scenarios where the lookup is something that is not likely to be changed.
Several issues here:
table datasheets are not suitable user interface for users.
you can create a saved QueryDef and if you view the properties of a field, the second tab is just like the second tab in table design, and allows you to use a combo box as your display type in your query. I would generally recommend against this, as, like table datasheets, a QueryDef is not a proper UI element, and if you use the saved query in other queries, you can run into the same problems that cause lookups in table fields to be such as bad idea.
you're building a UI, so use the tools that Access provides you for building a UI. That means a form. Your form's recordsource would have the bare data, and you'd create a combo box on your form that is bound to the field in the table behind your form, and displays the values from the lookup tables. There's a wizard to step you through this. If you like the look of datasheets so much (column sizing, sorting, show/hiding are all features that are nice in datasheets), you can set your form to display as a datasheet.
My advice is that for building a user interface, use the tools Access provides for creating user interface. In my opinion, a dropdown list belongs in a form, and nowhere else. While I occasionally might add one to a query for quick-and-dirty editing, I would never do that in objects that users are going to use.
I asked about setting up an in-memory dataset with TClientDataset, and was told I had to use the "Create Data Set" command in the form designer. That works just fine until I try to create a master-detail database relation. If I have a field def of type ftDataSet, then running the Create Data Set command (or calling the method at runtime) gives an "Invalid Field Type" error. I did a few searches and found that other people have had this problem before, but nobody ever seems to come up with an answer. Does anyone know how to fix this?
Instead of putting your detail in a ftDataSet column, just use a unique integer or GUID for the key reference, and place the detail data in a different TClientDataSet and have that key. Like you would in a normal database. Each TClientDataSet representing a different table.
If you create a field of type ftDataSet, you need to define the dataset, else the type is not valid.
You can define the dataset, by:
select the field.
select the ChildDefs property and click the [...] button.
add the fields.
Now you can create the dataset. Unless one of the children is of type ftDataSet in which case you have to recursively repeat the process.
A nasty problem that cost me a lot of time already. Finally I found a workaround, described here (Thanks you guys!):
http://www.delphigroups.info/3/6/171869.html
Summary: The culprit are the field definitions of the master client dataset, i.e., the one that contains the ftDataset fields. As soon as the field definitions of the master client dataset are not empty, the command CreateDataSet fails with the above described error message ("Invalid Field Type").
Workaround:
Create master-detail tables as instructed, but make sure the field definitions are empty when doing CreateDataset:
a) Designtime: Before you do "master dataset | RightClick | Create DataSet" in the design form, you have to click on the master dataset, go to object inspector, click on FieldDefs, and delete all the fields in the FieldDefs window. (The very first time you built the master dataset there are none in there anyway, but later there are.) Only then do Create Dataset. (I tried this myself with Delphi 2007; it works.)
b) Runtime: Call [Name of Masterdataset].FieldDefs.Clear before you do [Name of Masterdataset].CreateDataSet. (I did not try this out myself, but it is credibly described in the above named link.)
If this was too complicated, please look in the above mentioned link.