I'm fairly new with EF and got myself rather confused about what's going on with my solution.
I'm in the situation where my code appears to be working however the changes aren't being written to the database that I would expect.
I'm using Web Developer 2010 and SQL 2008, code first approach but choosing to make my own changes in the database and manually ensure my classes match correctly.
Things seemed ok until I came across an error where the db hash wasn't what entity framework was expecting, so I looked at modelBuilder.Conventions.Remove(); which wasn't available - it seems that's not around in the later versions. So, I figured if the later versions doesn't do this check, I'll go ahead and remove my reference to EF 4 and put the 4.3 dll in it's place. I think I also ended up deleting and renaming my database. That didn't work, so I followed up on something I found on Scott Gu's blog about naming your dbContext the same as the database, which seemed to help.
However I'm now getting the most bizarre scenario. My code is running, the data is saving, but it's not saving to my database. In fact I'm running a profile trace on the db and it doesn't even seem to be trying to connect. I can change my connection string to something invalid too, but my code will happily run, storing the data #somewhere#
Any ideas what's going on? Might it be using a local database or cache that I'm unaware of? Should I just start my small project again and pretend this never happened? That'd be the professional approach, right?
I would suggest to use Database first approach, if you have your Database set, or want to have maximum control over database.
Related
I was having some trouble bulk-loading records to go faster than what cursor.executemany would allow. I hoped the bulk operations documented with regular MonetDB here might work, so I tried an export as a test. e.g. cursor.execute("COPY SELECT * FROM foo INTO '/file/path.csv'"). This doesn't raise an error unless the file already exists, but the resulting file is always 0 bytes. I tried the same with file STDOUT and it prints nothing.
Are these COPY commands meant to work on the embedded version?
Note: This is my first use of anything related to MonetDB. As a fan of SQLite and a not-super-impressed user of Amazon Redshift, this seemed like a neat project. Not sure if MonetDB/e is the same as MonetDBLite - the former seems more active lately?
Exporting data through a COPY INTO command should be possible in MonetDB/e, yes.
However, this feature is not working currently. I was able to reproduce your problem, i.e. the COPY INTO creates the file where the data should be exported to, but doesn't write the data. This does not happen with regular MonetDB.
Our team is notified of this issue, and we're looking into it. Thanks for the heads up!
PS: Regarding your doubt about MonetDB/e vs MonetDBLite: our team no long develops and maintains MonetDBLite. Both are embedded databases that use MonetDB as the core engine, but MonetDBLite is deprecated. After having learnt some do's and don'ts with MonetDBLite, our team is developing our next generation of embedded databases.
So for your embedded database needs, you should follow what's coming out of our MonetDB/e projects.
I've created a test for it at: https://github.com/MonetDBSolutions/monetdbe-examples/blob/CI/C/copy_into.c
Also filed a bug report over on GitHub: https://github.com/MonetDB/MonetDB/issues/7058
We're currently looking into this issue.
I'm extremely new to programming. Just above school level. I created a project using EF Model First only to realize after I cannot get it to use SimpleMembership for Login, etc.
I wanted to try and solve this problem whilst remaining model-first as I asked here: https://stackoverflow.com/questions/36552439/could-someone-explain-this-code-to-me-ef-model-first-mvc
However, due to lack of response I'm considering just migrating the project to code first. I know that it is possible but I've been following tutorials online to no avail.
Could someone please explain to me how to properly move to code first. I'm even willing to recreate the program if necessary as long as it does not take too long.
I'd really appreciate some help.
Thanks
This really has been answered here.
I think you should really consider moving to ASP.NET Identity Membership, it's much more robust and has plenty of nice features without being difficult to manage. This is a really nice tutorial.
As for EF Code/Model first, you're thinking of them as something that defines your project; but really, they define a database CONTEXT. In other words, you can use both! Now don't get crazy, things can get sloppy quickly. But there is nothing that stops you from pulling in an existing set of tables and building models from them, but then adding another context to promote your classes into a database.
If you think of it as "switching" your project, you're getting it backward. And regardless, to get your models and database to sync, you need to either migrate your models or import your tables into EF. But it's a specific action you take, nothing happens magically. You COULD write your classes to perfectly mirror your database, create your EF models, and everything would work without you doing any direct connection (though you'd have a bit of a migraine afterward).
So don't worry about moving from one to the other. Just add a new context if you have a specific need to manage classes across different contexts.
But seriously, look at ASP.NET Identity to make all these problems go away...
We are looking to introduce odac into our application but I am running into a number of issues and I can't seem to find any solutions that fix our issues.
We are using an oracle database and trying to use ODAC 12c Release 1 (12.1.0.1.0) with Oracle Developer Tools for Visual Studio.
In our model we would like to have multiple schemas so we can perform cross schema queries. The schemas which we select in the filter for the database connection appear when we are creating the model. However when we try to update our model from the database only the default schema is visible. Sometimes this can be fixed by opening the relevant part of the database in Server Explorer in Visual Studio but this doesn't always work. This fix never works after we add multiple connection strings for the same model (depending on the location of the user will depend on which database the user gets directed to).
The next issue we are having is that we can't the return types of stored procedures to be auto-generate. I have tried to retrieve the column information but it is never able to retrieve the metadata. I have seen a few suggestions of modifying the stored procedures then getting the column information and reverting the stored procedures but this is something we would like to avoid. Also the suggestions don't seem to work on oracle databases (but that could be me, I don't have much experience with databases).
The final issue (this is a minor issue) is that I cannot figure out how to get the generate code to omit underscores from the classes/methods generated. This isn't a huge issue it is purely to make it easier migrating the code we have.
Whenever I Import I find lots of errors that since the database hasn't been worked with this tool, we did not have to fight case sensitive issues, nor views with unreferenced tables and a lot of other stuff that didn't worry us when we were on DevEnv.
Beacuse of this, I resolved to try working somewhat disconnected as a transitional state. but without loosing the TFS code repo or issue tracker.
Is it possible to work on sqlprojects and be able to validate and deploy code without having to import the database into the proj?
If it is, how?
#Edit:
Ok, so I've been asked to maintain the self DB reference inside the queries from within SP's, since DTSs execute some of those SP's, and it should evaluate the references without error.
(I'll be posting more stuff.)
When you use the Code First EF approach and just point to ./SQLEXPRESS, EF nicely builds your tables for you, defines all the fields, etc.
But it doesn't seem to work that way when you direct your connection string to add an .MDF file in /App_Data instead. Is that working as intended? The tutorials I'm finding on this, such as this one, show the tables in the .MDF being created by hand.
But I have not seen any documentation anywhere plainly state that Code First EF will build your tables one way but not the other, so I'm frankly just confused. Any illumination or advice on this would be greatly appreciated!
ETA: Okay, I see that this tutorial I linked is for the database-first approach, not code-first. In other places I'm reading that EF should, in theory, populate an App_Data/.mdf file the same way. But it still won't for me; if I give it an empty .mdf file to work with it refuses to add tables; if I don't give it an empty .mdf it tries to build one in my C:/Users/ directory.