We just created a new field in a database table, and so deleted, and re-inserted the table in the LINQ Class. The new database field appears in the LINQ Class in the diagram. However, when we're using the field, we get an error that says the table does not contain a definition for the field.
Any ideas on how we can solve this? Thanks!
UPDATE: What steps are required to update the LINQ to SQL Class? Maybe we're doing something wrong.
UPDATE 2: Picture of our problem - LINQ - http://img99.imageshack.us/img99/6033/usertable.png | Code - http://img43.imageshack.us/img43/5145/linqerror.png
Check the table def side of your mapping documents, either using properties in the designer, or by closing Studio and examining the XML. I recommend the designer.
Make sure the field name matches the field name in the database.
I've had problems with a few reserved keywords when using Linq2Entities, and I'd recommend you avoid reserved words in names (even though the [] handle them).
While this doesn't answer your question necessary, it may help to solve it - I've been a long time fan of the LINQ to SQL and Entities tools by Huagati. The re-sync aspect alone has saved me so much time, it's well worth the $50 (for the standard version) IMO.
http://www.huagati.com/dbmltools/
Hope it helps...
Edit:
In order to update the LINQ to SQL classes, you can either do it manually (bllurgh) or, you can remove them from the designer and drag-and-drop them from the Data Connections node in the Server Explorer.
I had to delete the entire LINQ Class, recreate it and re-add the tables for my problem to go away. Simply deleting a single table and re-adding it, or deleting all tables in the class and re-adding them did not work either.
I was having exactly the same issue, but I found that deleting the problematic tables in the Object Relational Designer and re-adding them (and re-adding the associations as well) solved the issue. I did not have to delete the entire DataContext, nor did I have to delete any of the tables that were still working properly. I would recommend trying this first before doing anything more drastic.
Related
How to fix ID in modification of application?
This problem will appear after changing database, and importing version control with set parameters:
cover by system tables and shared
does not search for existing records
index update during import
The problem is that on a few tables will show an error message:
sql database reported an error
Do a full synchronize of the database.
Beware, it may remove then reinsert fields or tables, if the id changed.
If you know the exact issue, you can write a job to manually fix it.
This is a more advanced task, so if you're not totally comfortable with it, I'd try Jan's approach.
ReleaseUpdateDB::changeTableId(...);
ReleaseUpdateDB::changeFieldId(...);
ReleaseUpdateDB::change* stuff
Also, Martin wrote a job that does a lot of it for you. I had to tweak it myself before:
http://dev.goshoom.net/en/2011/11/id-change/
I'm encountering a very odd problem. Since 2 days I cannot add new tables from my db in the model.
They appear in the list of addable tables, no error are shown at the validation but then, they don't appear in the Entity lists, and they still appear in the "addable" part of the menu.
The problem appears in
We've tried from different computeurs, so it's not a problem of my specific visual studio.
We've tried with other dbs, and the problem doesn't affect them. It affects boths of my prod and developpment dbs though.
We've tried with the exact same credentials to log to the db (not window authentication as we usually do), and the problem remains, so it's not a problem of rights.
We're a bit out of ideas right now :/
Does someone have an idea what it could be?
Thanks
Ok, we've found where it came from.
The table we wanted to add had no PK, and then when we tested we created mock tables without PK.
Once we add a PK the import goes well =)
If you're using a Code First approach then Entity Framework will build the table for you. It looks like you are not using Code First, so you will have create the table in the database. I assume you're using an Entity Data Model (.edmx)? If so, you will create your table in the database, then update your data model (.edmx). If you have not yet created your .edmx file, you need to do that - the .edmx file will contain all your CRUD operations.
What I'm confused about is I'd imagine your code would throw an error if the table did not exist (i.e. if the table represented by your data model didn't map to an actual table in the database, because it doesn't exist). So, the question is, does your table already exist? If it does, then step through the code line by line to find out why your records aren't being saved. If it doesn't exist, then add the table via SQL Server Management Studio (or similar), then open your .edmx file, right click on the layout that comes up, click "Update Model from database".
i use C++ Builder with SQLite database. I connect with the database through DBExpress. The problem is that DBGrid shows (WIDEMEMO) in every field and not the exact values that the database has.
I dont have this problem with other databases such as Firebird for example.
Why this behaviour? am i missing something with sqlite and how can be fixed.
Do u suggest me use SQLite / Firebird or other embeded database for a small standalone application.
Thanks in advance.
I am using FireDAC in Delphi and had the same problem.
I have resolved this issue by changing the dataset TWideMemoField DisplayValue property from dvClass to dvFull. Now my DBGrid works as expected.
I know this question is old but since it doesn't have any answer selected I will throw in my two cents. I recently came across the same problem and found a solution that might work for you as well.
This problem exists in your C++ DataSet and your SQLite. As it turns out that when you have a field with no defined size especially a text field, that field will be treated like a widememo or Memo in your DBGrid. So, what you need to do is define your text field with specific numbers of characters i.e. VARCHAR(10).
That's what I did and it work for me. I am using MySQL and Delphi with DBGrid.
This is a problem with the DBGrid. It doesn't handle the WIDEMEMO. See link for help with this.
Displaying and editing MEMO fields in Delphi's TDBGrid
I am currently working to rework the data system of our application. Basically, it is designed so that people can add all the custom fields they want, with only a few constant/always-there fields.
Our current design is giving us plenty of maintenance problems. What we do is dynamically(at runtime) add a column to the database for each field. We have to have a meta table and other cruft to maintain all of these dynamic columns.
Now we are looking at EAV, but it doesn't seem much better. Basically, we have many different types of fields, so there would be a StringValues, IntegerValues, etc table... which makes things that much worse.
I am wondering if using JSON or XML blobs in the database may be a better solution, specifically because in most use cases, when we retrieve anything out of these tables, we need the entire row. The problems is that we need to be able to create reports for this data as well.. No solution really makes custom queries look easy. And searching across such a blob database will surely be a performance nightmare when reports are ran.
Each "row" needs to have anywhere from about 15 to 100(possibly more) attributes/columns associated with it.
We are using SQL Server 2008 and our application interfacing with the database is a C# web application(so, ASP.Net).
what do you think? Use EAV or blobs or something else entirely? (Also, yes, I know a schema free database like MongoDB would be awesome here, but I can't convince my boss to use it)
What about the xml datatype? Advanced querying is possible against this type.
We've used the xml type with good success. We do most of our heavy lifting at the code level using linq to parse out values. Our schema is somewhat fixed, so that may not be an option for you.
One interesting feature of SQL server is the sql_variant type. It's fully supported in .NET and quite easy to use. The advantages is you don't need to create StringValue, IntValue, etc... columns, just one Value column that can contain all the simple types.
This very specific type favors the EAV option, IMHO.
It has some drawbacks though (sorting, distinct selects, etc...). So if you want to use it, make sure you read all the documentation and understand its limit.
Create a table with your known columns and "X" sparse columns using a sequential name such as DataColumn0001, DataColumn0002, etc. When there is a definition for a new column just rename a column and start inserting data. The great advantage to the sparse column is it is indexable.
More info at this link.
What you're doing is STUPID with a database that doesn't support your data type. You should work with a medium that meets your needs which include NoSQL databases such as RavenDB, MongoDB, DocumentDB, CouchBase or Postgres in RDMBS to name several.
You are inherently using the tool in a capacity it was neither designed for, and one it specifically attempts to limit you from achieving success. NoSQL database solutions frequently use JSON as an underlying storage because JSON is inherently schemaless. Want to add a property? Sure go ahead, want to add a whole sub collection? Sure go ahead. NoSQL databases were in part, created specifically to remove rigid schema requirements of RDBMS.
2015 Edit: Postgres now natively supports JSON. This is a viable option for RDBMS. My answer is still correct that you need to use the correct tool for the problem. It is a polygot persistence world.
Is it a bad idea (and if why?) to add a a column to the auto generated asp.net (ASPNETDB.MDF, visual studio 2008, mvc framework) "user roles - database"?
(E.g I want to add the columns RealName and LastName to the aspnet_Users table in the database.)
The reason I want to add a column instead of creating an entire new table is to avoid the doule maintenance issue and unnecessary redundancy
There are two generation schemes that are used (from Pragmatic Programmer):
Those that are used once to generate code
Those that are used all the time to have some code synced
The ones that are used for syncing, the results should not be modified, since they could be overridden at a later date when the generation gets done again.
In the case of your generated asp.net database, there is no reason for you to rerun the generation, so it would be OK to edit it.
The only scenario under which you would rerun the generation of the db is if microsoft releases a new version of the users database and you want to use the new one (in this case you might have to edit some parts of your application, so you could readd those two fields), or if you want to regenerate the database with different options. Both of these happen if you are not happy with your current db.
In my opinion that autogenerated database should be replaced by a normal table in application database or at least there should be an official solution to this problem.
I heard that this is quite good solution: http://www.asp.net/downloads/sandbox/table-profile-provider-samples/
why dont you create a new table with a Foriegn Key restraint? It seems like a bad idea to add a column to the aspnetdb...it will be a nightmare if you ever need to recreate your db...
First, those tables aren't really anything specific to MVC: they're created by/for the default AspNetSqlMembershipProvider. (Also applies to other kinds of ASP.NET applications.)
You could probably add new columns safely, but the membership provider wouldn't "see" them. It does provide its profile mechanism to store extra information (which gets serialized, and stored in the aspnet_Profiles table).
If you need to store lots of additional information about the user, you might also check out this sample membership provider that stores profile information in first-class tables, rather that in profile blobs.