|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Application development pointersHi
I have been developing vb/access but am new to sql server.Is there a sample vb.net/sql server app somewhere that I can use to pick some pointer on how to develop sql server apps in vb.net? Any other pointers will also be appreciated. Many Thanks Regards John, there is a LOT more to learning SQL Server over JET/Access development
than changing Connection Strings. I've written several books on the subject and the ones still available would go a long way to bringing you up to speed. See my website for more details. -- Show quoteHide quote__________________________________________________________________________ William R. Vaughn President and Founder Beta V Corporation Author, Mentor, Dad, Grandpa Microsoft MVP (425) 556-9205 (Pacific time) Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition) http://betav.com http://betav.com/blog/billva ____________________________________________________________________________________________ "John" <info@nospam.infovis.co.uk> wrote in message news:eeXUEg20JHA.1380@TK2MSFTNGP05.phx.gbl... > Hi > > I have been developing vb/access but am new to sql server.Is there a > sample vb.net/sql server app somewhere that I can use to pick some pointer > on how to develop sql server apps in vb.net? Any other pointers will also > be appreciated. > > Many Thanks > > Regards > The following paper discusses Access/SQL Server in the context of
using Access as a front-end, but it will nevertheless be helpful in understanding the differences between the two engines, which will be critical to succeeding on a server-based platform -- http://msdn.microsoft.com/en-us/library/bb188204.aspx. There isn't a lot of documentation about how Jet works as contrasted with SQL Server--this is pretty much it. OTOH, there's lots of VB/.NET resources out there -- good luck with the project ;-) --Mary Show quoteHide quote On Wed, 13 May 2009 02:13:25 +0100, "John" <info@nospam.infovis.co.uk> wrote: >Hi > >I have been developing vb/access but am new to sql server.Is there a sample >vb.net/sql server app somewhere that I can use to pick some pointer on how >to develop sql server apps in vb.net? Any other pointers will also be >appreciated. > >Many Thanks > >Regards > Hi Mary,
Is it really so difficult to go from Access to SQL server. But Bill and you live in Redmond. There you learn probably first to fly a spaceshutle before you step on a bicycle and later a car. Here we have to do it with a scooter. Cor Actually, I live in Florida and unlike Bill, I have no corporate jet
much less a space shuttle. Having been MVP from 1995 to 2004 when I joined msft, I've seen a world of trouble from people who have come to grief in various migration scenarios, so I can categorically state with great authority that YES, it really can be quite difficult to go from Access to SQL Server. They are totally different database engines, and ignorance is not your friend should you ever have to make that journey from the desktop to a server RDBMS. --Mary On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" <Notmyfirstn***@planet.nl> wrote: Show quoteHide quote >Hi Mary, > >Is it really so difficult to go from Access to SQL server. > >But Bill and you live in Redmond. There you learn probably first to fly a >spaceshutle before you step on a bicycle and later a car. > >Here we have to do it with a scooter. > >Cor Mary Chipman [MSFT] wrote:
> Actually, I live in Florida and unlike Bill, I have no corporate jet +1> much less a space shuttle. Having been MVP from 1995 to 2004 when I > joined msft, I've seen a world of trouble from people who have come to > grief in various migration scenarios, so I can categorically state > with great authority that YES, it really can be quite difficult to go > from Access to SQL Server. They are totally different database > engines, and ignorance is not your friend should you ever have to make > that journey from the desktop to a server RDBMS. Back around 2002/3, we switched from our ACCESS sales database to Web-Based ODBC/SQL. It was not a piece of cake. :-) Probably what may it easier was that MySQL had a ACCESS converter which created schema and *.SQL files. Probably the main reason why the migration project was pushed. I'm sure MSSQL has a converter? no? After that, it was a matter of creation the HTML/GUI access to it - that more tedious part of the project. I recall (but not the details) even writing something that recreated the SWITCH menu panels into a HTML menuing layout. That gave us the project task outline. If MSQL does not have a converter, you might want to use another tool to create the schema and definition SQL files, then use that to adjust/import into MSSQL. But I suspect this is the easy part and a non-issue. -- But in many respects ADO.NET abstracts the database engines from us.
All that is needed to understand are standard SQL and learn about procedures possibly. Maybe years of using DB's has clouded my judgement but having written Oracle and SQL and My SQL and in my dreary past Access I fail to see how it is that big a step if you have a good grounding in SQL / SQL DML. Yes all the stuff under the hood takes time but if you are migrating an Access DB do you really need to know this? If he was migrating from Access to oracle I would say he would struggle but Access to SQL Server, yes there will be a learning curve but the difference in ADO.NET terms should be minimal. Show quoteHide quote "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in message news:5dmo1514kn6frrha4o6guddha6r230q123@4ax.com... > Actually, I live in Florida and unlike Bill, I have no corporate jet > much less a space shuttle. Having been MVP from 1995 to 2004 when I > joined msft, I've seen a world of trouble from people who have come to > grief in various migration scenarios, so I can categorically state > with great authority that YES, it really can be quite difficult to go > from Access to SQL Server. They are totally different database > engines, and ignorance is not your friend should you ever have to make > that journey from the desktop to a server RDBMS. > > --Mary > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > <Notmyfirstn***@planet.nl> wrote: > >>Hi Mary, >> >>Is it really so difficult to go from Access to SQL server. >> >>But Bill and you live in Redmond. There you learn probably first to fly a >>spaceshutle before you step on a bicycle and later a car. >> >>Here we have to do it with a scooter. >> >>Cor The relational engine may be abstracted away from the programmability
layer, but it's still there, and if you don't have a good grounding in relational engine fundamentals (which is not a requirement for using Access successfully), then you are guaranteed to encounter difficulties if your application is at all complex or problematical. A straight port of a failed Access app is almost guaranteed to be worse in SQL Server when server and network overhead is added to the mix. So I'd say that migrating may be no big deal for a person such as yourself who does know their way around the block, but you are by no means in the majority of people who post to the newsgroups on the subject ;-) --Mary On Wed, 27 May 2009 12:57:07 +0100, "Paul" <paulri***@novareconsulting.com> wrote: Show quoteHide quote >But in many respects ADO.NET abstracts the database engines from us. > >All that is needed to understand are standard SQL and learn about procedures >possibly. Maybe years of using DB's has clouded my judgement but having >written Oracle and SQL and My SQL and in my dreary past Access I fail to see >how it is that big a step if you have a good grounding in SQL / SQL DML. > >Yes all the stuff under the hood takes time but if you are migrating an >Access DB do you really need to know this? If he was migrating from Access >to oracle I would say he would struggle but Access to SQL Server, yes there >will be a learning curve but the difference in ADO.NET terms should be >minimal. > > >"Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in message >news:5dmo1514kn6frrha4o6guddha6r230q123@4ax.com... >> Actually, I live in Florida and unlike Bill, I have no corporate jet >> much less a space shuttle. Having been MVP from 1995 to 2004 when I >> joined msft, I've seen a world of trouble from people who have come to >> grief in various migration scenarios, so I can categorically state >> with great authority that YES, it really can be quite difficult to go >> from Access to SQL Server. They are totally different database >> engines, and ignorance is not your friend should you ever have to make >> that journey from the desktop to a server RDBMS. >> >> --Mary >> >> On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" >> <Notmyfirstn***@planet.nl> wrote: >> >>>Hi Mary, >>> >>>Is it really so difficult to go from Access to SQL server. >>> >>>But Bill and you live in Redmond. There you learn probably first to fly a >>>spaceshutle before you step on a bicycle and later a car. >>> >>>Here we have to do it with a scooter. >>> >>>Cor > Hi Mary,
You are right I probably just don't think about it but just do it. I suppose with access allowing you to create a UI as well as just persistence the problem can cover BLL, UI not just persistence, and with the ability to create a non standard structure comes some re-design. Paul Show quoteHide quote "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in message news:q80r15hn5jm9mtua5nebj3fo1cp3d06mip@4ax.com... > The relational engine may be abstracted away from the programmability > layer, but it's still there, and if you don't have a good grounding in > relational engine fundamentals (which is not a requirement for using > Access successfully), then you are guaranteed to encounter > difficulties if your application is at all complex or problematical. A > straight port of a failed Access app is almost guaranteed to be worse > in SQL Server when server and network overhead is added to the mix. So > I'd say that migrating may be no big deal for a person such as > yourself who does know their way around the block, but you are by no > means in the majority of people who post to the newsgroups on the > subject ;-) > > --Mary > > On Wed, 27 May 2009 12:57:07 +0100, "Paul" > <paulri***@novareconsulting.com> wrote: > >>But in many respects ADO.NET abstracts the database engines from us. >> >>All that is needed to understand are standard SQL and learn about >>procedures >>possibly. Maybe years of using DB's has clouded my judgement but having >>written Oracle and SQL and My SQL and in my dreary past Access I fail to >>see >>how it is that big a step if you have a good grounding in SQL / SQL DML. >> >>Yes all the stuff under the hood takes time but if you are migrating an >>Access DB do you really need to know this? If he was migrating from Access >>to oracle I would say he would struggle but Access to SQL Server, yes >>there >>will be a learning curve but the difference in ADO.NET terms should be >>minimal. >> >> >>"Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in message >>news:5dmo1514kn6frrha4o6guddha6r230q123@4ax.com... >>> Actually, I live in Florida and unlike Bill, I have no corporate jet >>> much less a space shuttle. Having been MVP from 1995 to 2004 when I >>> joined msft, I've seen a world of trouble from people who have come to >>> grief in various migration scenarios, so I can categorically state >>> with great authority that YES, it really can be quite difficult to go >>> from Access to SQL Server. They are totally different database >>> engines, and ignorance is not your friend should you ever have to make >>> that journey from the desktop to a server RDBMS. >>> >>> --Mary >>> >>> On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" >>> <Notmyfirstn***@planet.nl> wrote: >>> >>>>Hi Mary, >>>> >>>>Is it really so difficult to go from Access to SQL server. >>>> >>>>But Bill and you live in Redmond. There you learn probably first to fly >>>>a >>>>spaceshutle before you step on a bicycle and later a car. >>>> >>>>Here we have to do it with a scooter. >>>> >>>>Cor >> Yup, there's always tradeoffs between ease of use and application
complexity when it comes to products and tools like Access, VS or even SSMS. Unsophisticated users are able to create applications which later on fail from their own success as they grow in size, scope and # of users. Tchniques that were fine on the desktop often fail miserably at the server, which has a steep and unforgiving learning curve. The original developer (or the person who inherited the app) may not have the expertise necessary to take it to the next level, so they turn up on the newsgroups or forums looking for help. Sometimes we "experts" tend to assume a level of prior knowledge that may not actually exist. --Mary On Thu, 28 May 2009 11:21:07 +0100, "Paul" <paulri***@novareconsulting.com> wrote: Show quoteHide quote >Hi Mary, > >You are right I probably just don't think about it but just do it. I suppose >with access allowing you to create a UI as well as just persistence the >problem can cover BLL, UI not just persistence, and with the ability to >create a non standard structure comes some re-design. > >Paul > > > >"Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in message >news:q80r15hn5jm9mtua5nebj3fo1cp3d06mip@4ax.com... >> The relational engine may be abstracted away from the programmability >> layer, but it's still there, and if you don't have a good grounding in >> relational engine fundamentals (which is not a requirement for using >> Access successfully), then you are guaranteed to encounter >> difficulties if your application is at all complex or problematical. A >> straight port of a failed Access app is almost guaranteed to be worse >> in SQL Server when server and network overhead is added to the mix. So >> I'd say that migrating may be no big deal for a person such as >> yourself who does know their way around the block, but you are by no >> means in the majority of people who post to the newsgroups on the >> subject ;-) >> >> --Mary >> >> On Wed, 27 May 2009 12:57:07 +0100, "Paul" >> <paulri***@novareconsulting.com> wrote: >> >>>But in many respects ADO.NET abstracts the database engines from us. >>> >>>All that is needed to understand are standard SQL and learn about >>>procedures >>>possibly. Maybe years of using DB's has clouded my judgement but having >>>written Oracle and SQL and My SQL and in my dreary past Access I fail to >>>see >>>how it is that big a step if you have a good grounding in SQL / SQL DML. >>> >>>Yes all the stuff under the hood takes time but if you are migrating an >>>Access DB do you really need to know this? If he was migrating from Access >>>to oracle I would say he would struggle but Access to SQL Server, yes >>>there >>>will be a learning curve but the difference in ADO.NET terms should be >>>minimal. >>> >>> >>>"Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in message >>>news:5dmo1514kn6frrha4o6guddha6r230q123@4ax.com... >>>> Actually, I live in Florida and unlike Bill, I have no corporate jet >>>> much less a space shuttle. Having been MVP from 1995 to 2004 when I >>>> joined msft, I've seen a world of trouble from people who have come to >>>> grief in various migration scenarios, so I can categorically state >>>> with great authority that YES, it really can be quite difficult to go >>>> from Access to SQL Server. They are totally different database >>>> engines, and ignorance is not your friend should you ever have to make >>>> that journey from the desktop to a server RDBMS. >>>> >>>> --Mary >>>> >>>> On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" >>>> <Notmyfirstn***@planet.nl> wrote: >>>> >>>>>Hi Mary, >>>>> >>>>>Is it really so difficult to go from Access to SQL server. >>>>> >>>>>But Bill and you live in Redmond. There you learn probably first to fly >>>>>a >>>>>spaceshutle before you step on a bicycle and later a car. >>>>> >>>>>Here we have to do it with a scooter. >>>>> >>>>>Cor >>> > Do you even know what ADO.NET is? I hope you're not referring to
"hacks" like Linq, MVC framework, and any guaranteed to fail RAD techniques. Get a book on application architecture and design patterns. Show quoteHide quote On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > But in many respects ADO.NET abstracts the database engines from us. > > All that is needed to understand are standard SQL and learn about procedures > possibly. Maybe years of using DB's has clouded my judgement but having > written Oracle and SQL and My SQL and in my dreary past Access I fail to see > how it is that big a step if you have a good grounding in SQL / SQL DML. > > Yes all the stuff under the hood takes time but if you are migrating an > Access DB do you really need to know this? If he was migrating from Access > to oracle I would say he would struggle but Access to SQL Server, yes there > will be a learning curve but the difference in ADO.NET terms should be > minimal. > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > joined msft, I've seen a world of trouble from people who have come to > > grief in various migration scenarios, so I can categorically state > > with great authority that YES, it really can be quite difficult to go > > from Access to SQL Server. They are totally different database > > engines, and ignorance is not your friend should you ever have to make > > that journey from the desktop to a server RDBMS. > > > --Mary > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > <Notmyfirstn***@planet.nl> wrote: > > >>Hi Mary, > > >>Is it really so difficult to go from Access to SQL server. > > >>But Bill and you live in Redmond. There you learn probably first to fly a > >>spaceshutle before you step on a bicycle and later a car. > > >>Here we have to do it with a scooter. > > >>Cor If that was aimed at me. Then Yes, and I do not use Linq or MVC.
ADO.NET is still an abstraction. I would run rings around you in application architecture and design patterns. Good day. <sqlg***@live.com> wrote in message news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... Do you even know what ADO.NET is? I hope you're not referring to"hacks" like Linq, MVC framework, and any guaranteed to fail RAD techniques. Get a book on application architecture and design patterns. Show quoteHide quote On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > But in many respects ADO.NET abstracts the database engines from us. > > All that is needed to understand are standard SQL and learn about > procedures > possibly. Maybe years of using DB's has clouded my judgement but having > written Oracle and SQL and My SQL and in my dreary past Access I fail to > see > how it is that big a step if you have a good grounding in SQL / SQL DML. > > Yes all the stuff under the hood takes time but if you are migrating an > Access DB do you really need to know this? If he was migrating from Access > to oracle I would say he would struggle but Access to SQL Server, yes > there > will be a learning curve but the difference in ADO.NET terms should be > minimal. > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > joined msft, I've seen a world of trouble from people who have come to > > grief in various migration scenarios, so I can categorically state > > with great authority that YES, it really can be quite difficult to go > > from Access to SQL Server. They are totally different database > > engines, and ignorance is not your friend should you ever have to make > > that journey from the desktop to a server RDBMS. > > > --Mary > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > <Notmyfirstn***@planet.nl> wrote: > > >>Hi Mary, > > >>Is it really so difficult to go from Access to SQL server. > > >>But Bill and you live in Redmond. There you learn probably first to fly > >>a > >>spaceshutle before you step on a bicycle and later a car. > > >>Here we have to do it with a scooter. > > >>Cor Haha, don't make me laugh. How exactly do you expect ADO.NET to
"abstract" the database engine from you without using hacks like MVC and Linq?? Do you know what abstraction is? Get yourself a beginners level book on software engineering. Show quoteHide quote On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > ADO.NET is still an abstraction. > > I would run rings around you in application architecture and design > patterns. > > Good day. > > <sqlg***@live.com> wrote in message > > news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... > Do you even know what ADO.NET is? I hope you're not referring to > "hacks" like Linq, MVC framework, and any guaranteed to fail > RAD techniques. > Get a book on application architecture and design patterns. > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > But in many respects ADO.NET abstracts the database engines from us. > > > All that is needed to understand are standard SQL and learn about > > procedures > > possibly. Maybe years of using DB's has clouded my judgement but having > > written Oracle and SQL and My SQL and in my dreary past Access I fail to > > see > > how it is that big a step if you have a good grounding in SQL / SQL DML.. > > > Yes all the stuff under the hood takes time but if you are migrating an > > Access DB do you really need to know this? If he was migrating from Access > > to oracle I would say he would struggle but Access to SQL Server, yes > > there > > will be a learning curve but the difference in ADO.NET terms should be > > minimal. > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > > joined msft, I've seen a world of trouble from people who have come to > > > grief in various migration scenarios, so I can categorically state > > > with great authority that YES, it really can be quite difficult to go > > > from Access to SQL Server. They are totally different database > > > engines, and ignorance is not your friend should you ever have to make > > > that journey from the desktop to a server RDBMS. > > > > --Mary > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > <Notmyfirstn***@planet.nl> wrote: > > > >>Hi Mary, > > > >>Is it really so difficult to go from Access to SQL server. > > > >>But Bill and you live in Redmond. There you learn probably first to fly > > >>a > > >>spaceshutle before you step on a bicycle and later a car. > > > >>Here we have to do it with a scooter. > > > >>Cor So using ADO.NET directly without MVC or Linq am I not abstracted from
1. Communication Protocol? 2. Database engine? Whether you like it or not ADO.NET itself is an abstraction to a DB's interfaces and over communication protocols for talking to those interfaces. Linq is an ORM abstraction, and probably over ADO.NET although not using Linq I don't know that. BTW there is no need to be an A$$. <sqlg***@live.com> wrote in message news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com... Haha, don't make me laugh. How exactly do you expect ADO.NET to"abstract" the database engine from you without using hacks like MVC and Linq?? Do you know what abstraction is? Get yourself a beginners level book on software engineering. Show quoteHide quote On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > ADO.NET is still an abstraction. > > I would run rings around you in application architecture and design > patterns. > > Good day. > > <sqlg***@live.com> wrote in message > > news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... > Do you even know what ADO.NET is? I hope you're not referring to > "hacks" like Linq, MVC framework, and any guaranteed to fail > RAD techniques. > Get a book on application architecture and design patterns. > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > But in many respects ADO.NET abstracts the database engines from us. > > > All that is needed to understand are standard SQL and learn about > > procedures > > possibly. Maybe years of using DB's has clouded my judgement but having > > written Oracle and SQL and My SQL and in my dreary past Access I fail to > > see > > how it is that big a step if you have a good grounding in SQL / SQL DML. > > > Yes all the stuff under the hood takes time but if you are migrating an > > Access DB do you really need to know this? If he was migrating from > > Access > > to oracle I would say he would struggle but Access to SQL Server, yes > > there > > will be a learning curve but the difference in ADO.NET terms should be > > minimal. > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > > joined msft, I've seen a world of trouble from people who have come to > > > grief in various migration scenarios, so I can categorically state > > > with great authority that YES, it really can be quite difficult to go > > > from Access to SQL Server. They are totally different database > > > engines, and ignorance is not your friend should you ever have to make > > > that journey from the desktop to a server RDBMS. > > > > --Mary > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > <Notmyfirstn***@planet.nl> wrote: > > > >>Hi Mary, > > > >>Is it really so difficult to go from Access to SQL server. > > > >>But Bill and you live in Redmond. There you learn probably first to > > >>fly > > >>a > > >>spaceshutle before you step on a bicycle and later a car. > > > >>Here we have to do it with a scooter. > > > >>Cor So you're telling me that you actually write SQL queries WITHOUT
knowing what type of database engine you're querying against? Or even knowing the proprietary implementations of that database vendor that may actually be more efficient and faster? Also, aren't you using custom drivers/providers for different DB vendors? Or do you just use a quick RAD tool to generate applications for you? Now, that's abstraction! Show quoteHide quote On May 28, 8:29 am, "Paul" <paulri***@novareconsulting.com> wrote: > So using ADO.NET directly without MVC or Linq am I not abstracted from > > 1. Communication Protocol? > 2. Database engine? > > Whether you like it or not ADO.NET itself is an abstraction to a DB's > interfaces and over communication protocols for talking to those interfaces. > > Linq is an ORM abstraction, and probably over ADO.NET although not using > Linq I don't know that. > > BTW there is no need to be an A$$. > > <sqlg***@live.com> wrote in message > > news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com... > Haha, don't make me laugh. How exactly do you expect ADO.NET to > "abstract" the database engine from you without using hacks like MVC > and Linq?? Do you know what abstraction is? Get yourself a beginners > level book on software engineering. > > On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > > ADO.NET is still an abstraction. > > > I would run rings around you in application architecture and design > > patterns. > > > Good day. > > > <sqlg***@live.com> wrote in message > > >news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com.... > > Do you even know what ADO.NET is? I hope you're not referring to > > "hacks" like Linq, MVC framework, and any guaranteed to fail > > RAD techniques. > > Get a book on application architecture and design patterns. > > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > But in many respects ADO.NET abstracts the database engines from us. > > > > All that is needed to understand are standard SQL and learn about > > > procedures > > > possibly. Maybe years of using DB's has clouded my judgement but having > > > written Oracle and SQL and My SQL and in my dreary past Access I fail to > > > see > > > how it is that big a step if you have a good grounding in SQL / SQL DML. > > > > Yes all the stuff under the hood takes time but if you are migrating an > > > Access DB do you really need to know this? If he was migrating from > > > Access > > > to oracle I would say he would struggle but Access to SQL Server, yes > > > there > > > will be a learning curve but the difference in ADO.NET terms should be > > > minimal. > > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > > > joined msft, I've seen a world of trouble from people who have come to > > > > grief in various migration scenarios, so I can categorically state > > > > with great authority that YES, it really can be quite difficult to go > > > > from Access to SQL Server. They are totally different database > > > > engines, and ignorance is not your friend should you ever have to make > > > > that journey from the desktop to a server RDBMS. > > > > > --Mary > > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > > <Notmyfirstn***@planet.nl> wrote: > > > > >>Hi Mary, > > > > >>Is it really so difficult to go from Access to SQL server. > > > > >>But Bill and you live in Redmond. There you learn probably first to > > > >>fly > > > >>a > > > >>spaceshutle before you step on a bicycle and later a car. > > > > >>Here we have to do it with a scooter. > > > > >>Cor LOL
Yes I do write SQL queries that can be used in multiple DB types and I have a DB Provider of my own over ADO.NET that allows me to distinguish vendor providers at runtime. I do not always need such functionality but as it is written why not re-use it. I have used the SQLClient, The ODP.NET and MySQL.NET specific providers, the funny thing is although there are some differences as you point out specifically around DBTypes enums especially they all seem to use the ADO.NET architecture. I never use a RAD tool and if you read some of my posts you would know I do not rate Linq and the like, hence why I took offence. Yes using these is more obvious abstraction. But when you talk to SQL Server do you code the communication protocol and code sending the SQL to a stream that the server understands. NO because all that is abstracted from you by the vendors ADO.NET implementation/driver. Funny enough thats also abstraction. Bye <sqlg***@live.com> wrote in message news:924c6f31-9388-4eb7-9e39-5b760e7624aa@e24g2000vbe.googlegroups.com... So you're telling me that you actually write SQL queries WITHOUTknowing what type of database engine you're querying against? Or even knowing the proprietary implementations of that database vendor that may actually be more efficient and faster? Also, aren't you using custom drivers/providers for different DB vendors? Or do you just use a quick RAD tool to generate applications for you? Now, that's abstraction! Show quoteHide quote On May 28, 8:29 am, "Paul" <paulri***@novareconsulting.com> wrote: > So using ADO.NET directly without MVC or Linq am I not abstracted from > > 1. Communication Protocol? > 2. Database engine? > > Whether you like it or not ADO.NET itself is an abstraction to a DB's > interfaces and over communication protocols for talking to those > interfaces. > > Linq is an ORM abstraction, and probably over ADO.NET although not using > Linq I don't know that. > > BTW there is no need to be an A$$. > > <sqlg***@live.com> wrote in message > > news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com... > Haha, don't make me laugh. How exactly do you expect ADO.NET to > "abstract" the database engine from you without using hacks like MVC > and Linq?? Do you know what abstraction is? Get yourself a beginners > level book on software engineering. > > On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > > ADO.NET is still an abstraction. > > > I would run rings around you in application architecture and design > > patterns. > > > Good day. > > > <sqlg***@live.com> wrote in message > > >news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... > > Do you even know what ADO.NET is? I hope you're not referring to > > "hacks" like Linq, MVC framework, and any guaranteed to fail > > RAD techniques. > > Get a book on application architecture and design patterns. > > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > But in many respects ADO.NET abstracts the database engines from us. > > > > All that is needed to understand are standard SQL and learn about > > > procedures > > > possibly. Maybe years of using DB's has clouded my judgement but > > > having > > > written Oracle and SQL and My SQL and in my dreary past Access I fail > > > to > > > see > > > how it is that big a step if you have a good grounding in SQL / SQL > > > DML. > > > > Yes all the stuff under the hood takes time but if you are migrating > > > an > > > Access DB do you really need to know this? If he was migrating from > > > Access > > > to oracle I would say he would struggle but Access to SQL Server, yes > > > there > > > will be a learning curve but the difference in ADO.NET terms should be > > > minimal. > > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > > > joined msft, I've seen a world of trouble from people who have come > > > > to > > > > grief in various migration scenarios, so I can categorically state > > > > with great authority that YES, it really can be quite difficult to > > > > go > > > > from Access to SQL Server. They are totally different database > > > > engines, and ignorance is not your friend should you ever have to > > > > make > > > > that journey from the desktop to a server RDBMS. > > > > > --Mary > > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > > <Notmyfirstn***@planet.nl> wrote: > > > > >>Hi Mary, > > > > >>Is it really so difficult to go from Access to SQL server. > > > > >>But Bill and you live in Redmond. There you learn probably first to > > > >>fly > > > >>a > > > >>spaceshutle before you step on a bicycle and later a car. > > > > >>Here we have to do it with a scooter. > > > > >>Cor You use your own DB provider? I think you don't know the difference
between utility implementation and provider. I think you meant that you use your own DB utility and not provider. Provider is a driver for the DB. For an example, for Oracle, the provider is Oracle.DataAccess driver and the implementation DB "utility" is OracleCommand, OracleConnection and other tools. It's also a shame an expert like you does not know about the ADO.NET "Common" framework which works for any database (DbCommand ring any bells?) but I guess reinventing the wheel with a custom "utility not provider" is better. Also, how are you writing complex SQL queries that work for any database vendor????? It must be very simple queries. As of yet, no DB vendor fully supports ANSI standard but you should already know that. I guess you don't need to know about the columns you're querying against or the DB structure or any of that. It's all abstracted right? Get a beginner level book on .NET Framework architecture. Show quoteHide quote On May 28, 9:12 am, "Paul" <paulri***@novareconsulting.com> wrote: > LOL > > Yes I do write SQL queries that can be used in multiple DB types and I have > a DB Provider of my own over ADO.NET that allows me to distinguish vendor > providers at runtime. I do not always need such functionality but as it is > written why not re-use it. > > I have used the SQLClient, The ODP.NET and MySQL.NET specific providers, the > funny thing is although there are some differences as you point out > specifically around DBTypes enums especially they all seem to use the > ADO.NET architecture. > > I never use a RAD tool and if you read some of my posts you would know I do > not rate Linq and the like, hence why I took offence. Yes using these is > more obvious abstraction. > > But when you talk to SQL Server do you code the communication protocol and > code sending the SQL to a stream that the server understands. NO because all > that is abstracted from you by the vendors ADO.NET implementation/driver. > Funny enough thats also abstraction. > > Bye > > <sqlg***@live.com> wrote in message > > news:924c6f31-9388-4eb7-9e39-5b760e7624aa@e24g2000vbe.googlegroups.com... > So you're telling me that you actually write SQL queries WITHOUT > knowing what type of database engine you're querying against? Or even > knowing the proprietary implementations of that database vendor that > may actually be more efficient and faster? Also, aren't you using > custom drivers/providers for different DB vendors? > > Or do you just use a quick RAD tool to generate applications for you? > Now, that's abstraction! > > On May 28, 8:29 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > So using ADO.NET directly without MVC or Linq am I not abstracted from > > > 1. Communication Protocol? > > 2. Database engine? > > > Whether you like it or not ADO.NET itself is an abstraction to a DB's > > interfaces and over communication protocols for talking to those > > interfaces. > > > Linq is an ORM abstraction, and probably over ADO.NET although not using > > Linq I don't know that. > > > BTW there is no need to be an A$$. > > > <sqlg***@live.com> wrote in message > > >news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com.... > > Haha, don't make me laugh. How exactly do you expect ADO.NET to > > "abstract" the database engine from you without using hacks like MVC > > and Linq?? Do you know what abstraction is? Get yourself a beginners > > level book on software engineering. > > > On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > > > ADO.NET is still an abstraction. > > > > I would run rings around you in application architecture and design > > > patterns. > > > > Good day. > > > > <sqlg***@live.com> wrote in message > > > >news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com.... > > > Do you even know what ADO.NET is? I hope you're not referring to > > > "hacks" like Linq, MVC framework, and any guaranteed to fail > > > RAD techniques. > > > Get a book on application architecture and design patterns. > > > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > > But in many respects ADO.NET abstracts the database engines from us.. > > > > > All that is needed to understand are standard SQL and learn about > > > > procedures > > > > possibly. Maybe years of using DB's has clouded my judgement but > > > > having > > > > written Oracle and SQL and My SQL and in my dreary past Access I fail > > > > to > > > > see > > > > how it is that big a step if you have a good grounding in SQL / SQL > > > > DML. > > > > > Yes all the stuff under the hood takes time but if you are migrating > > > > an > > > > Access DB do you really need to know this? If he was migrating from > > > > Access > > > > to oracle I would say he would struggle but Access to SQL Server, yes > > > > there > > > > will be a learning curve but the difference in ADO.NET terms should be > > > > minimal. > > > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > > > Actually, I live in Florida and unlike Bill, I have no corporate jet > > > > > much less a space shuttle. Having been MVP from 1995 to 2004 when I > > > > > joined msft, I've seen a world of trouble from people who have come > > > > > to > > > > > grief in various migration scenarios, so I can categorically state > > > > > with great authority that YES, it really can be quite difficult to > > > > > go > > > > > from Access to SQL Server. They are totally different database > > > > > engines, and ignorance is not your friend should you ever have to > > > > > make > > > > > that journey from the desktop to a server RDBMS. > > > > > > --Mary > > > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > > > <Notmyfirstn***@planet.nl> wrote: > > > > > >>Hi Mary, > > > > > >>Is it really so difficult to go from Access to SQL server. > > > > > >>But Bill and you live in Redmond. There you learn probably first to > > > > >>fly > > > > >>a > > > > >>spaceshutle before you step on a bicycle and later a car. > > > > > >>Here we have to do it with a scooter. > > > > > >>Cor > It's also a shame an expert like you does not know about the ADO.NET This is flawed (well certain implementation are) and I touched on an example >"Common" framework which works for any database (DbCommand ring any >bells?) but I guess reinventing the wheel with a custom "utility not >provider" is better. above. Do a search on DBType mappings Oracle. Provider is a term used to describe a number of things. It is a specific layer I create to Abstract/Bridge these small differences in DB vendor implementations. But you would know that if you had actually used more than SQL Server. What I call it in my framework is particular to me. >Also, how are you writing complex SQL queries that work for any LOL. Good design negates the use for complexity within the database. surely >database vendor????? It must be very simple queries. As of yet, no DB >vendor fully supports ANSI standard but you should already know that. as a guru you know that, and any complexities should be an exception to the rule rather than the rule and these can be hadled by my Provider or Bridge or Facade whatever suits your definition. >I guess you don't need to know about the columns you're querying Strangely enough I leave that to the ORM which is distinctly vendor provider >against or the DB structure or any of that. It's all abstracted right? specific free as it uses those wonderful ADO.NET intefaces or "Common" framework as you so eloquently put it. Its strange how you can formulate an argument against me that would have actually answered your own question if you actually knew what you were talking about. I get the impression you are someone who talks rather than does, specifically getting hung up on semantics. Your not worth the time. Show quoteHide quote On May 28, 9:12 am, "Paul" <paulri***@novareconsulting.com> wrote: > LOL > > Yes I do write SQL queries that can be used in multiple DB types and I > have > a DB Provider of my own over ADO.NET that allows me to distinguish vendor > providers at runtime. I do not always need such functionality but as it is > written why not re-use it. > > I have used the SQLClient, The ODP.NET and MySQL.NET specific providers, > the > funny thing is although there are some differences as you point out > specifically around DBTypes enums especially they all seem to use the > ADO.NET architecture. > > I never use a RAD tool and if you read some of my posts you would know I > do > not rate Linq and the like, hence why I took offence. Yes using these is > more obvious abstraction. > > But when you talk to SQL Server do you code the communication protocol and > code sending the SQL to a stream that the server understands. NO because > all > that is abstracted from you by the vendors ADO.NET implementation/driver. > Funny enough thats also abstraction. > > Bye > > <sqlg***@live.com> wrote in message > > news:924c6f31-9388-4eb7-9e39-5b760e7624aa@e24g2000vbe.googlegroups.com... > So you're telling me that you actually write SQL queries WITHOUT > knowing what type of database engine you're querying against? Or even > knowing the proprietary implementations of that database vendor that > may actually be more efficient and faster? Also, aren't you using > custom drivers/providers for different DB vendors? > > Or do you just use a quick RAD tool to generate applications for you? > Now, that's abstraction! > > On May 28, 8:29 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > So using ADO.NET directly without MVC or Linq am I not abstracted from > > > 1. Communication Protocol? > > 2. Database engine? > > > Whether you like it or not ADO.NET itself is an abstraction to a DB's > > interfaces and over communication protocols for talking to those > > interfaces. > > > Linq is an ORM abstraction, and probably over ADO.NET although not using > > Linq I don't know that. > > > BTW there is no need to be an A$$. > > > <sqlg***@live.com> wrote in message > > >news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com... > > Haha, don't make me laugh. How exactly do you expect ADO.NET to > > "abstract" the database engine from you without using hacks like MVC > > and Linq?? Do you know what abstraction is? Get yourself a beginners > > level book on software engineering. > > > On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > > > ADO.NET is still an abstraction. > > > > I would run rings around you in application architecture and design > > > patterns. > > > > Good day. > > > > <sqlg***@live.com> wrote in message > > > >news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... > > > Do you even know what ADO.NET is? I hope you're not referring to > > > "hacks" like Linq, MVC framework, and any guaranteed to fail > > > RAD techniques. > > > Get a book on application architecture and design patterns. > > > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > > But in many respects ADO.NET abstracts the database engines from us. > > > > > All that is needed to understand are standard SQL and learn about > > > > procedures > > > > possibly. Maybe years of using DB's has clouded my judgement but > > > > having > > > > written Oracle and SQL and My SQL and in my dreary past Access I > > > > fail > > > > to > > > > see > > > > how it is that big a step if you have a good grounding in SQL / SQL > > > > DML. > > > > > Yes all the stuff under the hood takes time but if you are migrating > > > > an > > > > Access DB do you really need to know this? If he was migrating from > > > > Access > > > > to oracle I would say he would struggle but Access to SQL Server, > > > > yes > > > > there > > > > will be a learning curve but the difference in ADO.NET terms should > > > > be > > > > minimal. > > > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > > > Actually, I live in Florida and unlike Bill, I have no corporate > > > > > jet > > > > > much less a space shuttle. Having been MVP from 1995 to 2004 when > > > > > I > > > > > joined msft, I've seen a world of trouble from people who have > > > > > come > > > > > to > > > > > grief in various migration scenarios, so I can categorically state > > > > > with great authority that YES, it really can be quite difficult to > > > > > go > > > > > from Access to SQL Server. They are totally different database > > > > > engines, and ignorance is not your friend should you ever have to > > > > > make > > > > > that journey from the desktop to a server RDBMS. > > > > > > --Mary > > > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > > > <Notmyfirstn***@planet.nl> wrote: > > > > > >>Hi Mary, > > > > > >>Is it really so difficult to go from Access to SQL server. > > > > > >>But Bill and you live in Redmond. There you learn probably first > > > > >>to > > > > >>fly > > > > >>a > > > > >>spaceshutle before you step on a bicycle and later a car. > > > > > >>Here we have to do it with a scooter. > > > > > >>Cor > This is flawed (well certain implementation are) and I touched on an example I guess you create applications without requirements,> above. Do a search on DBType mappings Oracle. Provider is a term used to > describe a number of things. It is a specific layer I create to > Abstract/Bridge these small differences in DB vendor implementations. But > you would know that if you had actually used more than SQL Server. What I > call it in my framework is particular to me. design,functional reqs, or documentation. If you had bothered to read the inference of DBType, you would know the exact mappings (http:// download.oracle.com/docs/html/B14164_01/featOraCommand.htm#i1007297). Blaming .NET for your ignorance is not the solution. Also, if you failed to read the documentation of the Oracle Provider (rookie error), then you would have created a conversion method for OracleDbType to DbType instead of writing a whole new DB "provider". > LOL. Good design negates the use for complexity within the database. surely Okay, so write me a ANSI standard paging query that works in any> as a guru you know that, and any complexities should be an exception to the > rule rather than the rule and these can be hadled by my Provider or Bridge > or Facade whatever suits your definition. database without the use of anything proprietary. You have done pagination before right?? > Strangely enough I leave that to the ORM which is distinctly vendor provider First you're against ORM, and now you say you use ORM. Which is it?> specific free as it uses those wonderful ADO.NET intefaces or "Common" > framework as you so eloquently put it. > You're applications are nothing more than 1-2-3-poof magic. > Its strange how you can formulate an argument against me that would have Do yourself a favor and get some beginner/dummy level books on> actually answered your own question if you actually knew what you were > talking about. I get the impression you are someone who talks rather than > does, specifically getting hung up on semantics. Your not worth the time. database architecture, application architecture, .NET framework architecture so you can stop writing 1-2-3-poof magic applications. Show quoteHide quote On May 28, 10:09 am, "Paul" <paulri***@novareconsulting.com> wrote: > > It's also a shame an expert like you does not know about the ADO.NET > >"Common" framework which works for any database (DbCommand ring any > >bells?) but I guess reinventing the wheel with a custom "utility not > >provider" is better. > > This is flawed (well certain implementation are) and I touched on an example > above. Do a search on DBType mappings Oracle. Provider is a term used to > describe a number of things. It is a specific layer I create to > Abstract/Bridge these small differences in DB vendor implementations. But > you would know that if you had actually used more than SQL Server. What I > call it in my framework is particular to me. > > >Also, how are you writing complex SQL queries that work for any > >database vendor????? It must be very simple queries. As of yet, no DB > >vendor fully supports ANSI standard but you should already know that. > > LOL. Good design negates the use for complexity within the database. surely > as a guru you know that, and any complexities should be an exception to the > rule rather than the rule and these can be hadled by my Provider or Bridge > or Facade whatever suits your definition. > > >I guess you don't need to know about the columns you're querying > >against or the DB structure or any of that. It's all abstracted right? > > Strangely enough I leave that to the ORM which is distinctly vendor provider > specific free as it uses those wonderful ADO.NET intefaces or "Common" > framework as you so eloquently put it. > > Its strange how you can formulate an argument against me that would have > actually answered your own question if you actually knew what you were > talking about. I get the impression you are someone who talks rather than > does, specifically getting hung up on semantics. Your not worth the time. > > On May 28, 9:12 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > LOL > > > Yes I do write SQL queries that can be used in multiple DB types and I > > have > > a DB Provider of my own over ADO.NET that allows me to distinguish vendor > > providers at runtime. I do not always need such functionality but as it is > > written why not re-use it. > > > I have used the SQLClient, The ODP.NET and MySQL.NET specific providers, > > the > > funny thing is although there are some differences as you point out > > specifically around DBTypes enums especially they all seem to use the > > ADO.NET architecture. > > > I never use a RAD tool and if you read some of my posts you would know I > > do > > not rate Linq and the like, hence why I took offence. Yes using these is > > more obvious abstraction. > > > But when you talk to SQL Server do you code the communication protocol and > > code sending the SQL to a stream that the server understands. NO because > > all > > that is abstracted from you by the vendors ADO.NET implementation/driver. > > Funny enough thats also abstraction. > > > Bye > > > <sqlg***@live.com> wrote in message > > >news:924c6f31-9388-4eb7-9e39-5b760e7624aa@e24g2000vbe.googlegroups.com.... > > So you're telling me that you actually write SQL queries WITHOUT > > knowing what type of database engine you're querying against? Or even > > knowing the proprietary implementations of that database vendor that > > may actually be more efficient and faster? Also, aren't you using > > custom drivers/providers for different DB vendors? > > > Or do you just use a quick RAD tool to generate applications for you? > > Now, that's abstraction! > > > On May 28, 8:29 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > So using ADO.NET directly without MVC or Linq am I not abstracted from > > > > 1. Communication Protocol? > > > 2. Database engine? > > > > Whether you like it or not ADO.NET itself is an abstraction to a DB's > > > interfaces and over communication protocols for talking to those > > > interfaces. > > > > Linq is an ORM abstraction, and probably over ADO.NET although not using > > > Linq I don't know that. > > > > BTW there is no need to be an A$$. > > > > <sqlg***@live.com> wrote in message > > > >news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com.... > > > Haha, don't make me laugh. How exactly do you expect ADO.NET to > > > "abstract" the database engine from you without using hacks like MVC > > > and Linq?? Do you know what abstraction is? Get yourself a beginners > > > level book on software engineering. > > > > On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > > > > ADO.NET is still an abstraction. > > > > > I would run rings around you in application architecture and design > > > > patterns. > > > > > Good day. > > > > > <sqlg***@live.com> wrote in message > > > > >news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... > > > > Do you even know what ADO.NET is? I hope you're not referring to > > > > "hacks" like Linq, MVC framework, and any guaranteed to fail > > > > RAD techniques. > > > > Get a book on application architecture and design patterns. > > > > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > > > But in many respects ADO.NET abstracts the database engines from us. > > > > > > All that is needed to understand are standard SQL and learn about > > > > > procedures > > > > > possibly. Maybe years of using DB's has clouded my judgement but > > > > > having > > > > > written Oracle and SQL and My SQL and in my dreary past Access I > > > > > fail > > > > > to > > > > > see > > > > > how it is that big a step if you have a good grounding in SQL / SQL > > > > > DML. > > > > > > Yes all the stuff under the hood takes time but if you are migrating > > > > > an > > > > > Access DB do you really need to know this? If he was migrating from > > > > > Access > > > > > to oracle I would say he would struggle but Access to SQL Server, > > > > > yes > > > > > there > > > > > will be a learning curve but the difference in ADO.NET terms should > > > > > be > > > > > minimal. > > > > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > > > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > > > > Actually, I live in Florida and unlike Bill, I have no corporate > > > > > > jet > > > > > > much less a space shuttle. Having been MVP from 1995 to 2004 when > > > > > > I > > > > > > joined msft, I've seen a world of trouble from people who have > > > > > > come > > > > > > to > > > > > > grief in various migration scenarios, so I can categorically state > > > > > > with great authority that YES, it really can be quite difficult to > > > > > > go > > > > > > from Access to SQL Server. They are totally different database > > > > > > engines, and ignorance is not your friend should you ever have to > > > > > > make > > > > > > that journey from the desktop to a server RDBMS. > > > > > > > --Mary > > > > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > > > > <Notmyfirstn***@planet.nl> wrote: > > > > > > >>Hi Mary, > > > > > > >>Is it really so difficult to go from Access to SQL server. > > > > > > >>But Bill and you live in Redmond. There you learn probably first > > > > > >>to > > > > > >>fly > > > > > >>a > > > > > >>spaceshutle before you step on a bicycle and later a car. > > > > > > >>Here we have to do it with a scooter. > > > > > > >>Cor I guess you create applications without requirements,
design,functional reqs, or documentation. If you had bothered to read the inference of DBType, you would know the exact mappings (http:// download.oracle.com/docs/html/B14164_01/featOraCommand.htm#i1007297). Blaming .NET for your ignorance is not the solution. Also, if you failed to read the documentation of the Oracle Provider (rookie error), then you would have created a conversion method for OracleDbType to DbType instead of writing a whole new DB "provider". Did I or didn't I read the documentation?make your mind up. Iam crazy to know where I should have put this translation? Some entity that we dare not call a provider, or ORM or DAL. Come on hotshot explain to us mortals rather than telling us to read books because that makes me think you are just a troll. > LOL. Good design negates the use for complexity within the database. Okay, so write me a ANSI standard paging query that works in any> surely > as a guru you know that, and any complexities should be an exception to > the > rule rather than the rule and these can be hadled by my Provider or Bridge > or Facade whatever suits your definition. database without the use of anything proprietary. You have done pagination before right?? Did you actually read what I put? Let me quote it again. 'any complexities should be an exception to the rule rather than the rule' I live in the real world unlike you so understand about exceptions. >First you're against ORM, and now you say you use ORM. Which is it? I create my own DAL/ORM that converts IDataReaders to model objects yes. I >You're applications are nothing more than 1-2-3-poof magic. said I dont use the entity framework/linq/datasets. >Do yourself a favor and get some beginner/dummy level books on You have no arguments you just come out with simpleton comments like this >database architecture, application architecture, .NET framework >architecture so you can stop writing 1-2-3-poof magic applications. and not only to me. Explain to us and elighten us how you would do it then and maybe then I will have more respect for you but for now your just one of those wanna bees who is all hot air. Show quoteHide quote On May 28, 10:09 am, "Paul" <paulri***@novareconsulting.com> wrote: > > It's also a shame an expert like you does not know about the ADO.NET > >"Common" framework which works for any database (DbCommand ring any > >bells?) but I guess reinventing the wheel with a custom "utility not > >provider" is better. > > This is flawed (well certain implementation are) and I touched on an > example > above. Do a search on DBType mappings Oracle. Provider is a term used to > describe a number of things. It is a specific layer I create to > Abstract/Bridge these small differences in DB vendor implementations. But > you would know that if you had actually used more than SQL Server. What I > call it in my framework is particular to me. > > >Also, how are you writing complex SQL queries that work for any > >database vendor????? It must be very simple queries. As of yet, no DB > >vendor fully supports ANSI standard but you should already know that. > > LOL. Good design negates the use for complexity within the database. > surely > as a guru you know that, and any complexities should be an exception to > the > rule rather than the rule and these can be hadled by my Provider or Bridge > or Facade whatever suits your definition. > > >I guess you don't need to know about the columns you're querying > >against or the DB structure or any of that. It's all abstracted right? > > Strangely enough I leave that to the ORM which is distinctly vendor > provider > specific free as it uses those wonderful ADO.NET intefaces or "Common" > framework as you so eloquently put it. > > Its strange how you can formulate an argument against me that would have > actually answered your own question if you actually knew what you were > talking about. I get the impression you are someone who talks rather than > does, specifically getting hung up on semantics. Your not worth the time. > > On May 28, 9:12 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > LOL > > > Yes I do write SQL queries that can be used in multiple DB types and I > > have > > a DB Provider of my own over ADO.NET that allows me to distinguish > > vendor > > providers at runtime. I do not always need such functionality but as it > > is > > written why not re-use it. > > > I have used the SQLClient, The ODP.NET and MySQL.NET specific providers, > > the > > funny thing is although there are some differences as you point out > > specifically around DBTypes enums especially they all seem to use the > > ADO.NET architecture. > > > I never use a RAD tool and if you read some of my posts you would know I > > do > > not rate Linq and the like, hence why I took offence. Yes using these is > > more obvious abstraction. > > > But when you talk to SQL Server do you code the communication protocol > > and > > code sending the SQL to a stream that the server understands. NO because > > all > > that is abstracted from you by the vendors ADO.NET > > implementation/driver. > > Funny enough thats also abstraction. > > > Bye > > > <sqlg***@live.com> wrote in message > > >news:924c6f31-9388-4eb7-9e39-5b760e7624aa@e24g2000vbe.googlegroups.com... > > So you're telling me that you actually write SQL queries WITHOUT > > knowing what type of database engine you're querying against? Or even > > knowing the proprietary implementations of that database vendor that > > may actually be more efficient and faster? Also, aren't you using > > custom drivers/providers for different DB vendors? > > > Or do you just use a quick RAD tool to generate applications for you? > > Now, that's abstraction! > > > On May 28, 8:29 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > So using ADO.NET directly without MVC or Linq am I not abstracted from > > > > 1. Communication Protocol? > > > 2. Database engine? > > > > Whether you like it or not ADO.NET itself is an abstraction to a DB's > > > interfaces and over communication protocols for talking to those > > > interfaces. > > > > Linq is an ORM abstraction, and probably over ADO.NET although not > > > using > > > Linq I don't know that. > > > > BTW there is no need to be an A$$. > > > > <sqlg***@live.com> wrote in message > > > >news:5f1c9900-cf42-4276-8fd5-b6a7a7c07c13@s20g2000vbp.googlegroups.com... > > > Haha, don't make me laugh. How exactly do you expect ADO.NET to > > > "abstract" the database engine from you without using hacks like MVC > > > and Linq?? Do you know what abstraction is? Get yourself a beginners > > > level book on software engineering. > > > > On May 28, 6:08 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > > If that was aimed at me. Then Yes, and I do not use Linq or MVC. > > > > > ADO.NET is still an abstraction. > > > > > I would run rings around you in application architecture and design > > > > patterns. > > > > > Good day. > > > > > <sqlg***@live.com> wrote in message > > > > >news:574ddc2a-daf0-460c-90d3-297cca7a91a4@g20g2000vba.googlegroups.com... > > > > Do you even know what ADO.NET is? I hope you're not referring to > > > > "hacks" like Linq, MVC framework, and any guaranteed to fail > > > > RAD techniques. > > > > Get a book on application architecture and design patterns. > > > > > On May 27, 7:57 am, "Paul" <paulri***@novareconsulting.com> wrote: > > > > > > But in many respects ADO.NET abstracts the database engines from > > > > > us. > > > > > > All that is needed to understand are standard SQL and learn about > > > > > procedures > > > > > possibly. Maybe years of using DB's has clouded my judgement but > > > > > having > > > > > written Oracle and SQL and My SQL and in my dreary past Access I > > > > > fail > > > > > to > > > > > see > > > > > how it is that big a step if you have a good grounding in SQL / > > > > > SQL > > > > > DML. > > > > > > Yes all the stuff under the hood takes time but if you are > > > > > migrating > > > > > an > > > > > Access DB do you really need to know this? If he was migrating > > > > > from > > > > > Access > > > > > to oracle I would say he would struggle but Access to SQL Server, > > > > > yes > > > > > there > > > > > will be a learning curve but the difference in ADO.NET terms > > > > > should > > > > > be > > > > > minimal. > > > > > > "Mary Chipman [MSFT]" <mc***@online.microsoft.com> wrote in > > > > > messagenews:5dmo1514kn6frrha4o6guddha6r230q***@4ax.com... > > > > > > > Actually, I live in Florida and unlike Bill, I have no corporate > > > > > > jet > > > > > > much less a space shuttle. Having been MVP from 1995 to 2004 > > > > > > when > > > > > > I > > > > > > joined msft, I've seen a world of trouble from people who have > > > > > > come > > > > > > to > > > > > > grief in various migration scenarios, so I can categorically > > > > > > state > > > > > > with great authority that YES, it really can be quite difficult > > > > > > to > > > > > > go > > > > > > from Access to SQL Server. They are totally different database > > > > > > engines, and ignorance is not your friend should you ever have > > > > > > to > > > > > > make > > > > > > that journey from the desktop to a server RDBMS. > > > > > > > --Mary > > > > > > > On Mon, 18 May 2009 20:01:37 +0200, "Cor Ligthert[MVP]" > > > > > > <Notmyfirstn***@planet.nl> wrote: > > > > > > >>Hi Mary, > > > > > > >>Is it really so difficult to go from Access to SQL server. > > > > > > >>But Bill and you live in Redmond. There you learn probably first > > > > > >>to > > > > > >>fly > > > > > >>a > > > > > >>spaceshutle before you step on a bicycle and later a car. > > > > > > >>Here we have to do it with a scooter. > > > > > > >>Cor > Did I or didn't I read the documentation?make your mind up. Iam crazy to Troll, you would put this conversion method preferably in your custom> know where I should have put this translation? Some entity that we dare not > call a provider, or ORM or DAL. Come on hotshot explain to us mortals rather > than telling us to read books because that makes me think you are just a > troll. common framework. You do have a custom framework right? There is no need for your "provider" to be in the custom framework cause the ADO.NET "common" framework already has a perfect implementation for all databases. You're supposed to read the DB vendor's .NET provider for the inference of DBType. > I create my own DAL/ORM that converts IDataReaders to model objects yes. I First you said you used a "provider". Now you use an ORM and now> said I dont use the entity framework/linq/datasets. you're getting your DAL and ORM mixed up. > Troll, you would put this conversion method preferably in your custom No it does not or I would have used it.> common framework. You do have a custom framework right? There is no > need for your "provider" to be in the custom framework cause the > ADO.NET "common" framework already has a perfect implementation for > all databases. You're supposed to read the DB vendor's .NET provider > for the inference of DBType. Map a Clob to dbtype then map back again to a sqldbtype. Wow you can't without abstracting it off and thats just one example for ODP.NET and SQLClient, think of all those other providers. Before you tell me to read that document trust me I read it years ago. I came up with a solution then that works and still does you don't like it, then im still waiting for your expert advice on how it should really be done. >> I create my own DAL/ORM that converts IDataReaders to model objects yes. No Im not Do you know the difference between a DAL and an ORM or should I >> I >> said I dont use the entity framework/linq/datasets. > First you said you used a "provider". Now you use an ORM and now > you're getting your DAL and ORM mixed up. say similarities. I have an abstraction that allows me to create a DAL/ORM with no reference to Specific ADO.NET providers. It also allows me to still do database specific tasks and gain performance benefits associated with specific vendor providers. I'm still waiting to here what you would do but feel I will be waiting for some time. > No Im not Do you know the difference between a DAL and an ORM or should I You clearly don't know what a DAL or ORM is.> say similarities. > > I have an abstraction that allows me to create a DAL/ORM with no reference > to Specific ADO.NET providers. It also allows me to still do database > specific tasks and gain performance benefits associated with specific vendor > providers. > > I'm still waiting to here what you would do but feel I will be waiting for > some time. Let me explain to you in "beginner/dummy" terms that you can understand: ORM maps entities to database tables and automatically takes care of data operations such as persistence and loading. It works for any applications and sometimes, any DB vendor. ORM examples are nHibernate and ORM.NET. DAL (data access layer) takes care of the data operations, you define the methods needed. Multiple applications may go through the same DAL (physical tier). Also, did you just say that ORMs give performance benefits? Have you read the performance issues with nHibernate and also how ORM sometimes generate non-optimized sql? You are an idiot. Lets be straight.
First you never read what I said, and second I asked the difference/similarities between an ORM and a DAL and you scraped the surface. You clearly do not understand all you claim. Secondly, I was talking about provider when I mentioned perfromance benefit, and If you actually understood anything about Data Access as a whole then you would understand what I was saying. Finally you just totaly skiped my question about dbType mapping. I personally have nothing to prove so If you wish to remain ignorant then so be it. <sqlg***@live.com> wrote in message Show quoteHide quote news:41e9aef5-1f1f-46a1-9174-b72ec937494c@v4g2000vba.googlegroups.com... > >> No Im not Do you know the difference between a DAL and an ORM or should I >> say similarities. >> >> I have an abstraction that allows me to create a DAL/ORM with no >> reference >> to Specific ADO.NET providers. It also allows me to still do database >> specific tasks and gain performance benefits associated with specific >> vendor >> providers. >> >> I'm still waiting to here what you would do but feel I will be waiting >> for >> some time. > > You clearly don't know what a DAL or ORM is. > > Let me explain to you in "beginner/dummy" terms that you can > understand: > ORM maps entities to database tables and automatically takes care of > data operations such as persistence and loading. It works for any > applications and sometimes, any DB vendor. ORM examples are nHibernate > and ORM.NET. > DAL (data access layer) takes care of the data operations, you define > the methods needed. Multiple applications may go through the same DAL > (physical tier). > > Also, did you just say that ORMs give performance benefits? Have you > read the performance issues with nHibernate and also how ORM sometimes > generate non-optimized sql? You are an idiot. 
Other interesting topics
problem with RaiseEvents
detect file status Internal Server Error 500 remember a forms position on the screen Visual Basic 4.0 16/32 Capture Routines for .Net? Search for values in between two values in a string? Vb and Active Directory bold selected text Urgent: XP, Vista logoff application (WM_QUERYENDSESSION) refresh data on form |
|||||||||||||||||||||||
