I'm using Entity framework 5 with a database first approach. I created a new database table and updated my .edmx. The .cs file was not created for my Model.tt, as explained here this is a bug in VS 2012.
I followed the work arounds as explained in this thread and I eventually updated to VS2012.4. The .cs file is still not created for my new table, any idea why this is happening and how I can fix this?
Your Tables must have primary key to create .cs files.
I decided to delete my edmx file and create a new connection to the database, and this error:
Connection failed, your password expired
Needless to say, a lot of time could have been saved if entity framework at least warned me when updating my model from database that my password expired, instead of just 'Updating' as if nothing is wrong.
So I renewed my password and guess what, everything is working!
Are you using a source control system that could be setting the directory as read only ? I've seen that problem before where automated tools were not generating what they are supposed to be doing because of that.
If you are using source control, check out the whole directory, exit VS. Open it back again and try to generate again.
I've had this problem both with and without an .edmx file and both times the problem was the same. When you create and save a new table in SQL Server, EF can't see it until you click on Tables > Refresh in the Object Browser.
I had a similar problem and it turned out that my .context.tt file and my .tt file had the wrong .edmx file name in them for the inputFile string variable. I believe this occurred as a result of someone renaming the .edmx file at some point.
Related
So, I'm mantaining a software an ex co-worker did.
He uses an xsd to create TableAdapters for his reports and other stuff.
The thing is, I need to add a new TableAdapter and I get the aforementioned error. It also says the dread "A network-related or instance-specific error occurred while establishing a connection to SQL Server."
I am at loss here and I don't know what to do. Here are the facts:
I have 2 connection strings, one for the production environment and one for the development environment (my computer).
When I go to settings and then the edit window of the connection string, I hit "test connection" and it says it works fine.
Both SQL Server 2008R2 and Visual Studio 2010 are on the same machine, my machine.
I do not have a named instance.
I right click on the xsd design view and click "Add -> TableAdapter" and use the local connection string (the one I already tested and worked)
I click "Use existing stored procedures" and then hit [Next]. Then I am able to pick a stored procedure for the Select section and I can see the columns.
I click finish, the system locks for a while and then I get the error.
Named Pipes, TCP/IP are enabled in SQL Server configuration.
I'm kinda lost and I already wasted 2 days on this. I have tried what little I know and nothings works. I hope I can find help within your wisdom.
Sorry for the long post but I wanted to provide as much info as I could in one single shot.
OK, After some trial and error, I found the solution. At least, I made it work on my environment.
What #Rusland said, made me think and I searched for another Settings file. It did not exist. I decided then to erase the connection strings and the Settings file to see if the project compiled. As expected, it threw a ton of errors.
So, it was not the file.
I decided to add one by one the connection strings and test as I added them. The first one that I added, was the connection string used in development (localConStr). The configuration of the table adapter was as shown in the first image. As you can see, localConStr is selected (as has always been) only this time, having only one connection string I received an error, a different error than before. The one in the second image.
How could it be possible for the TableAdapter to ask for that Connection String if there were no refferences to it? I deleted it and the Connection property of my table adapter was set to the localConStr. So... I did what any desperate man would do: CTRL+F and find all refferences to rptTbl_loansAgingTableAdapter. My only reasoning was that somewhere in the code, the connection string was probably hardcoded by my predecessor. One thing worth mentioning: I specifically used "loansAgingTableAdapter" as the search criteria because that's the one TableAdapter I was trying to modify in the first instance.
After some minutes, I was navigating the XSD at code level (it's just an XML) and to my surprise, I found an element named Connection and there was not one but TWO!. Just to make things clear, this file has been untouched by me till today (I mean, I did not touch it by hand, any changes had been made by the IDE)
The two connection strings were:
<Connection AppSettingsObjectName="Settings" AppSettingsPropertyName="localConStr"...
and
<Connection AppSettingsObjectName="Settings" AppSettingsPropertyName="loanConStr" ...
Yes, I know they look very alike, but notice they are local and loan. I decided to delete the second one (loanConStr) since it was not in my Settings file anymore (loanConStr was the original connection string left by my predecessor, localConStr was created by me so that I could switch connection strings in runtime instead of modifying the connection string and recompile every time I had to make a change and deploy again).
After that, I made sure all the DataTables in my DataSet used the same connection string (localConStr) and recompiled. I then tried the things that were giving me troubles:
First: I created a new DataTable: the action was successful
Second: I modified an existing DataTable: success again
Last, but not least, I tried to execute the report. I ran the app and went to the report and success! Apparently, my problem is solved.
What had happened? I am not sure, but if I had to guess, I would say that the TableAdapter was trying to use a connection string that pointed to a server that did not exist in my network (my client's server) so, every time I tried to configure it or change anything, Visual Studio was unable to contact that server and that's why I gor the connection error.
Why was the TableAdapter trying to use that connection string when the local connection string was explicitly specified? I don't know, but leavin IN THE XSD only one connection string was my solution.
As a side note, you might ask "But Compa, what will happen when the user wants to run a report that uses the localConStr?" Simple, I change the connection string at runtime when the report window is opened with the one being used by the whole app.
Sorry for the long post, and if you want a TL;DR version:
Go to your xds dataset file, delete any unwanted connection strings and then go to design view and make sure all your TableAdapters use the only ConnectionString specified in your xsd
It looks like you're seeing the database just fine. (Thus you get a list of stored procedures).
Try the rights on the procedure itself.
GRANT EXECUTE on [dbo].[rpt_loansAging] to [TheSqlAuthenticationUserNameWeCannotSeeInTheScreenShot]
APPPEND
Since you've tried everything else, try opening up a new VS project (Same version of VS and Target Framework) and try adding a TableAdapter in the same way.
If that works, then you got voodoo going on. You could delete and recreate them in the original project.
Every blue moon, something goes awry with Visual Studio, ESPECIALLY projects that started out as VS2003, were upgraded to VS2005, maybe upgraded to VS2010 (whatever combination).
I had a project that I upgraded from VS2003 to VS2005, and it built fine on my computer. On the build machine, it started failing........No idea what it was.
I ended up seeing some small anomaly in the "By Project" references. I simply removed all "By Project" references (within the .sln solution) ... and re-added the "By Project" references, and it fixed everything.
Go figure.
Background...may or may not be relevant:
I had a hard drive crash and just recently rebuilt my laptop and added an SSD while I was at it. As a result, one of my development projects was not on a different drive. It was originally in source control using TFS I re-bound the solution and projects and everything seemed find.
I then did some db changes and did an Update Model from Database in my edmx file. The update worked fine, except that in the process it created an additional *.Context.tt and *.tt file (the one with the green + next to them in the pic below). so now the compiler is complaining about the duplicate references.
The whole edmx to tt to cs process is black magic to me at the moment so I'm not sure how to clean it up. Can I just delete them? Will it recreated them on the next update? Ideally would like to know and address the root cause so it doesn't happen the next time.
I have a problem with using different databases in a mvc application with Entity Framework 6. Our client will use a database of their own which could be a MySQL, PostgreSQL or Oracle database.
I have made an .edmx file for MySQL and PostgreSQL, these models work individually but if possible I want to use only one model for all databases. The databases will have identical tables and columns.
So want to make something like this:
using (var connection = new DbConnection())
{
string id = connection.Set<user>().First().Id;
}
The DbConnection has to be a connection to the right database (you can see which database to use in a resource file)
I am encountering the following problem with a database first approach:
I have read http://www.codeproject.com/Articles/82017/Preparing-an-Entity-Framework-model-for-multi-prov.aspx and when I followed the instructions I got a
MetadataException: Unable to load the specified metadata resource exception.
I have tried everything to find the .ssdl file but I just can't find it.
Am I doing it the right way or does anyone know if there is a better way to do this?
I tried doing exactly what you are trying to do but with MS SQL and Vista DB. I followed that tutorial and ran into the same problem.
By following the tutorial, you will have a separate ssdl file for each DB. Make sure you have set it to copy to output directory and then updated your connection string accordingly.
To set it to copy to the output folder, right click on the ssdl file in Solution Explorer and change "Copy to OUtput Directory" to "Copy if Newer".
Then change the metadata part of your connection string to something like this:
metadata=res://*/DataModel.csdl|c:\dev\program\bin\debug\DataModel.VistaDB.ssdl|res://*/DataModel.msl;
Notice the path to the ssdl is a folder path. The path I have hear is the path I used. You will need to change it accordingly
I have a need to try and repair a SQLite database from a .NET program if the database file gets corrupted. I have found several sites such as Fix SQLite and in the FAQ it describes that you can:
Depending how badly your database is corrupted, you may be able to recover some of the data by using the CLI to dump the schema and contents to a file and then recreate.
Does anyone know of a way to repair a SQLite database programmatically in .NET?
You might consider implementing your own strategy for database recovery. You could store backups of the SQLite file and then check that it is OK using:
PRAGMA integrity_check;
If errors are found then you can revert to a backup.
You are overlooking one important word: you can 'recover some data', this is not a repair!
If there is a sitatuation where a corrupted database could be repaired perfectly without user-interaction than it would not be corrupted in the first place and such an repair would have been a standard function of SQLite
I have an SSIS package that copies the data in a table from one SQL Server 2005 to another SQL Server 2005. I do this with a "Data Flow" task. In the package config file I expose the destination table name.
Problem is when I change the destination table name in the config file (via notepad) I get the following error "vs_needsnewmetadata". I think I understand the problem... the destination table column mapping is fixed when I first set up the package.
Question: what's the easiest way to do the above with an ssis package?
I've read online about setting up the metadata programmatically and all but I'd like to avoid this. Also I wrote a C# console app that does everything just fine... all tables etc are specified in the app.config ... but apparently this solution isn't good enough.
Have you set DelayValidation to False on the Data Source Destination properties? If not, try that.
Edit: Of course that should be DelayValidation to True, so it just goes ahead and tries rather than checking. Also, instead of altering your package in Notepad, why not put the table name in a variable, put the variable into an Expression on the destination, then expose the variable in a .DtsConfig configuration file? Then you can change that without danger.
Matching source destination column with case sensitive has done the work for me.
Like in my case SrNo_prod was column in dev and using it we developed the dtsx, while it is been created as SrNo_Prod in prod, after making case change from P to p, we got successful execution of package.
Check if the new destination table has the same columns as the old one.
I believe the error occurs if the columns are different, and the destination can no longer map its input columns to the table columns. If two tables have the same schema, this error should not occur.
If all you are doing is copying data from one SQL2005 server to another I would just create a Linked Server and use a stored proc to copy the data. An SSIS package is overkill.
How to Create linked server
Once the linked server is created you would just program something like...
INSERT INTO server1.dbo.database1.table1(id,name)
SELECT id, name FROM server2.dbo.database1.table1
As far the SSIS package I have always had to reopen and rebuild the package so that the meta data gets updated when modifying the tables column properties.