Made2Manage Database writing using EFCore, or things I wish I knew before goring myself on the unicorn's horn.
If you're reading this, and you're doing it on purpose, you're likely shocked that anyone is bothering on about trying to interact with Aptean's Made2Manage SQLServer database to begin with, mostly because you're not sure you should be doing it yourself.
But you've got an "INCREDIBLE IDEA!™" and come hell or high water, you're going to dive in and make it happen.
Ok, I can't blame you, I'm the same way.
So, the way I've chosen to tackle this is through using my good friend C# on the latest Language Version 9, .Net 5 release, with WPF DataGrid, MVVM with the help of the utterly fantastic framework Prism, which can be found on the Prism Website, and then learned about at Brian Lagunas' Youtube channel, which is unbelievably good, and last, but not least, EFCore.
The rest of this little post is going to be focused on the last part, specifically things that would have saved me the last few days of headache if I had known about them beforehand.
1. Let EFCore do the initial heavy lifting of writing your classes for you, at least at first.
EFCore has this incredibly good Database Scaffolding(link to video explanation) feature, where it goes in to your db, finds everything there in the tables and spits out POCOs for you, with the DbContext already auto-generated.
 |
| when you get to write less boring code |
It's awesome.
But it's not perfect.
It might be great for people without rigid constraints on how the database must remain, but we've got to do a little bit more work than most people because we're not just working with any old database, oh no, my friend, we are working with the Made2Manage SQL Server database.
 |
| Who puts in the mangle in Made2Manage? |
Why should that make a difference? A SQL Server database is a SQL Server database, right?
Well, usually, probably, yeah.. but not this time.
I can't imagine why, but for some reason Aptean built the database..
WITHOUT ANY PRIMARY KEYS..
 |
| It's all fun and games until someone doesn't build a proper database |
nada.
zip.
So, what do you do?
Well, you can't change it, don't want to upset your company's ERP software for goodness sake.
You change how EFCore looks at the database.
2. Use Identity Column instead of creating a new column.
You have to go into the DbContext that you created, and in the OnModelCreating method , scroll down to the table you want to work with, say, jomast for example.
As you can see, you have to do a sort of Jedi mind trick, hand wavey thing to get it to work.
 |
| No, he TOTALLY has a perfectly good Primary Key, I swear.. |
3. You have to treat an object like it's not attached automatically, because EF Core still won't get the hint.
No one likes a kid who says he'll do something and doesn't follow through.
EF Core docs and most learning resources say you're not going to have to worry about objects being automatically tracked if you're in a connected scenario like desktop development.
Unfortunately, that's not always true..
 |
| I got trust issues with you, Internet... and this is just one more brick in the wall.. |
You're going to have to make absolutely sure you attach your objects to the DbContext if you want their changes tracked.
4. No relationships.
One of the most awesome things about EFCore is that it automatically handles the relationships between your tables, so if there's a delete on one object, you can be sure it will properly cascade to the other tables that need to know..
Which would be great...
If this database actually had any foreign keys.
There are no actual relationships in this relational database... the tables... they are alone.
You're going to have to handle this nonsense yourself.
Haven't done this yet myself, so, you know..
Good luck!
Make sure to plan well, and buy your database administrator a pack of RedBull or something, because you're going to have to be on his or her good side.
Well, that's all I've got for now, have a great day, and let me know if you're interested in more.
Comments
Post a Comment