Hi Nick,
I haven't used Entity Framework ever and being a dot.net product I'm not sure how I could incorporate it in our VO Code. Did look it up and it is definitely the best solution, maybe you can point me in the right direction to learn how to use this is VO and later in XSharp to handle dBase databases and later on SQL tables.
Thanks,
John
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
-
NickFriend
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Hi John,
If you're moving to X# you're moving to .Net, so that's not an issue as such. However if you've already got it working with VO2ADO, as Robert said that's available for X#... or is this a different application?
With Entity Framework, you declare your db tables as objects, EF then creates a database according to the properties of those objects, and you can then use Linq to interrogate the db. This returns objects or lists of objects that you can then move around and use in the rest of your code.
Our main app has something like 30 projects, but we have data access highly isolated and so EF is only referenced in 2 of those projects. The rest work just with the resulting objects and know nothing about the database. So if you can achieve this sort of level of isolation you can potentially swap out the dbf data access and replace it with EF over sql and leave the rest of the app simply dealing with disconnected objects.
I don't think there's an option of DBF support in EF, but I may be wrong.
Nick
If you're moving to X# you're moving to .Net, so that's not an issue as such. However if you've already got it working with VO2ADO, as Robert said that's available for X#... or is this a different application?
With Entity Framework, you declare your db tables as objects, EF then creates a database according to the properties of those objects, and you can then use Linq to interrogate the db. This returns objects or lists of objects that you can then move around and use in the rest of your code.
Our main app has something like 30 projects, but we have data access highly isolated and so EF is only referenced in 2 of those projects. The rest work just with the resulting objects and know nothing about the database. So if you can achieve this sort of level of isolation you can potentially swap out the dbf data access and replace it with EF over sql and leave the rest of the app simply dealing with disconnected objects.
I don't think there's an option of DBF support in EF, but I may be wrong.
Nick
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Wow Nick, that is exactly what I want to do, we need a layer isolating direct data access from our programs. Is this something that could be implemented for dBase as well? In VO? Or only when we migrate to X#?
Where do we go from here to start experimenting with this? We had used VO2ADO in the past to connect to SQL from VO but I'm open to anything that could simplify our lives and strengthen program design.
Thanks,
John
Where do we go from here to start experimenting with this? We had used VO2ADO in the past to connect to SQL from VO but I'm open to anything that could simplify our lives and strengthen program design.
Thanks,
John
-
NickFriend
- Posts: 248
- Joined: Fri Oct 14, 2016 7:09 am
Moving complex VO2.7b dBase applications to XSharp and then migrating to MS SQL
Hi John,
This would be .Net only to be realistic. As far as handling DBFs goes, I'm afraid I've no idea. It would depend if anyone has done an EF provider for DBFs... maybe Advantage??
Phil Hepburn did quite a bit with EF, so you could start by having a look at his ClickStart notes (available here from the Help menu), and there are quite a few tutorials available online. Once you have an idea where you want to go I'll be happy to help (though I'm afraid I work in C# so some translation may be required).
Nick
This would be .Net only to be realistic. As far as handling DBFs goes, I'm afraid I've no idea. It would depend if anyone has done an EF provider for DBFs... maybe Advantage??
Phil Hepburn did quite a bit with EF, so you could start by having a look at his ClickStart notes (available here from the Help menu), and there are quite a few tutorials available online. Once you have an idea where you want to go I'll be happy to help (though I'm afraid I work in C# so some translation may be required).
Nick