I'm grappling with understanding some ADO.NET issues. I'd appreciate any help. If I write a .NET Windows application that uses ADO.NET, what needs to be distributed with my application in order for it to run for Customers using Windows Vista? I understood ADO.NET is included with the .NET frameworks. I also understood that Microsoft Mail uses a .NET database to index message files. This had me thinking that Vista systems had everything needed to run a Windows application that uses ADO.NET. But now I'm not so sure. Is it possible to write a .NET ADO.NET application without a database server such as SQL Server? If so, how? If not, then how do applications like Microsoft Mail work without SQL Server installed. Jonathan
What is Microsoft Mail? I know something from MS, such as Outlook, Outlook Express, Windows Mail, which is Outlook Expresss replacement on Vista. Haven't heard "MS Mail". ADO.NET application only requires .NET framework. Of couse, if your app need to access data stored in particular data source, such as SQL Server, Access Jet db..., your application has to know where the data source is and have permission to access it. It could be on the same computer, or on the network/the Internet somewhere. So, yes, it more than possible to write app using ADO.NET without SQL Server (or other database/database server, for this matter) installed on the same computer where your app sits. If your app does not use anything not included in .NET, you do not need distribute anything, as long as your user has .NET framework installed If the "MS Mail", as you mention and believe, requires SQL Server, then you have to get it installed. But this has nothing to do with your ADO.NET application, unless your application need to work with it. HTH [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:eQoGY%23K9HHA.1168@TK2MSFTNGP02.phx.gbl... > I'm grappling with understanding some ADO.NET issues. I'd appreciate any > help. > > If I write a .NET Windows application that uses ADO.NET, what needs to be > distributed with my application in order for it to run for Customers using > Windows Vista? > > I understood ADO.NET is included with the .NET frameworks. I also > understood that Microsoft Mail uses a .NET database to index message > files. This had me thinking that Vista systems had everything needed to > run a Windows application that uses ADO.NET. > > But now I'm not so sure. Is it possible to write a .NET ADO.NET > application without a database server such as SQL Server? If so, how? If > not, then how do applications like Microsoft Mail work without SQL Server > installed. > > Jonathan >
Norman, [quoted text, click to view] > What is Microsoft Mail? I know something from MS, such as Outlook, Outlook > Express, Windows Mail, which is Outlook Expresss replacement on Vista. > Haven't heard "MS Mail".
Yeah, Windows Mail. [quoted text, click to view] > So, yes, it more than possible to write app using ADO.NET without SQL > Server (or other database/database server, for this matter) installed on > the same computer where your app sits. If your app does not use anything > not included in .NET, you do not need distribute anything, as long as your > user has .NET framework installed
I'm just trying to figure out what type of database access doesn't require anything beyond ADO.NET. Every time I've connected to a database so far, it included a connection string that normally involves some type of database server. Can you tell me how to open a database in a way that does not require anything beyond ADO.NET? [quoted text, click to view] > If the "MS Mail", as you mention and believe, requires SQL Server, then > you have to get it installed. But this has nothing to do with your ADO.NET > application, unless your application need to work with it.
I have no reason to believe (and have not stated) that Windows Mail requires SQL Server, only that it uses the database included with the .NET framework. I'm just wondering what that database access looks like without involving anything other than a database file. Thanks. Jonathan
See >>> -- ____________________________________ William (Bill) Vaughn Author, Mentor, Consultant, Dad, Grandpa Microsoft MVP INETA Speaker www.betav.com www.betav.com/blog/billva Please reply only to the newsgroup so that others can benefit. This posting is provided "AS IS" with no warranties, and confers no rights. __________________________________ Visit www.hitchhikerguides.net to get more information on my latest book: Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition) and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook) ----------------------------------------------------------------------------------------------------------------------- [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:eQoGY%23K9HHA.1168@TK2MSFTNGP02.phx.gbl... > I'm grappling with understanding some ADO.NET issues. I'd appreciate any > help. > > If I write a .NET Windows application that uses ADO.NET, what needs to be > distributed with my application in order for it to run for Customers using > Windows Vista?
Well, when you create an application, you bind to objects exposed by one of the .NET Frameworks. There are at least 5 at this time: 1, 1.1, 2.0, 3.0 and 3.5. This means the targeted version of the framework must be installed on the system--you cannot take this for granted. [quoted text, click to view] > > I understood ADO.NET is included with the .NET frameworks. I also > understood that Microsoft Mail uses a .NET database to index message > files. This had me thinking that Vista systems had everything needed to > run a Windows application that uses ADO.NET. >>> Microsoft Mail (as I understand) uses the JET/RED database (or is it >>> BLUE). Anyway, it's not accessible by other applications. However, there >>> are small database management systems you can install at deploy-time or >>> simply included as DLLs in your application (see my EBook on the SQL >>> Server Compact Edition). > > But now I'm not so sure. Is it possible to write a .NET ADO.NET > application without a database server such as SQL Server? If so, how? If > not, then how do applications like Microsoft Mail work without SQL Server > installed. >>> Yes, you can create an application without using a DBMS engine to manage >>> the data, but I expect you would be re-inventing a number of cogs and >>> wheels--all of which are available for free in one form or another. > > Jonathan >
William, [quoted text, click to view] >>>> Yes, you can create an application without using a DBMS engine to >>>> manage the data, but I expect you would be re-inventing a number of >>>> cogs and wheels--all of which are available for free in one form or >>>> another.
So, if I want to access a database in a .NET application, are you saying I must either A) make certain the computer my application is running on has server software such as MS SQL Server installed, or B) I must bypass ADO.NET? There's no way ADO.NET can simply open and work with an MDF file directly without database server software? Jonathan
Jonathan, If you want to write a program that works with SQL Server data then you must go through SQL Server. There is no way to access SQL Server data with ADO.Net (or any other technology) without SQL Server. Kerry Moorman [quoted text, click to view] "Jonathan Wood" wrote: > William, > > >>>> Yes, you can create an application without using a DBMS engine to > >>>> manage the data, but I expect you would be re-inventing a number of > >>>> cogs and wheels--all of which are available for free in one form or > >>>> another. > > So, if I want to access a database in a .NET application, are you saying I > must either A) make certain the computer my application is running on has > server software such as MS SQL Server installed, or B) I must bypass > ADO.NET? > > There's no way ADO.NET can simply open and work with an MDF file directly > without database server software? > > Jonathan >
Jonathan, You could work with a non-server DBMS such as Access through ADO.Net without needing Access installed. But for any of the server-type DBMSs like SQL Server, Oracle, DB2, etc., you need the DBMS installed and then your ADO.Net code "talks to" the server DBMS. Kerry Moorman [quoted text, click to view] "Jonathan Wood" wrote: > What I'm asking is if it's possible to write an ADO.NET Windows application > that doesn't require or use any type of server software. If I can just > access the database file directly using the ADO.NET built in to the .NET > framework. > > If I'm still being unclear, for the purposes of this question, I do *NOT* > want the program to work with SQL Server. > > Jonathan > > "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in message > news:7623F44B-23B4-4D31-8312-09552659487E@microsoft.com... > > Jonathan, > > > > If you want to write a program that works with SQL Server data then you > > must > > go through SQL Server. > > > > There is no way to access SQL Server data with ADO.Net (or any other > > technology) without SQL Server. > > > > Kerry Moorman > > > > > > "Jonathan Wood" wrote: > > > >> William, > >> > >> >>>> Yes, you can create an application without using a DBMS engine to > >> >>>> manage the data, but I expect you would be re-inventing a number of > >> >>>> cogs and wheels--all of which are available for free in one form or > >> >>>> another. > >> > >> So, if I want to access a database in a .NET application, are you saying > >> I > >> must either A) make certain the computer my application is running on has > >> server software such as MS SQL Server installed, or B) I must bypass > >> ADO.NET? > >> > >> There's no way ADO.NET can simply open and work with an MDF file directly > >> without database server software? > >> > >> Jonathan > >> > >> >
What I'm asking is if it's possible to write an ADO.NET Windows application that doesn't require or use any type of server software. If I can just access the database file directly using the ADO.NET built in to the .NET framework. If I'm still being unclear, for the purposes of this question, I do *NOT* want the program to work with SQL Server. Jonathan [quoted text, click to view] "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in message news:7623F44B-23B4-4D31-8312-09552659487E@microsoft.com... > Jonathan, > > If you want to write a program that works with SQL Server data then you > must > go through SQL Server. > > There is no way to access SQL Server data with ADO.Net (or any other > technology) without SQL Server. > > Kerry Moorman > > > "Jonathan Wood" wrote: > >> William, >> >> >>>> Yes, you can create an application without using a DBMS engine to >> >>>> manage the data, but I expect you would be re-inventing a number of >> >>>> cogs and wheels--all of which are available for free in one form or >> >>>> another. >> >> So, if I want to access a database in a .NET application, are you saying >> I >> must either A) make certain the computer my application is running on has >> server software such as MS SQL Server installed, or B) I must bypass >> ADO.NET? >> >> There's no way ADO.NET can simply open and work with an MDF file directly >> without database server software? >> >> Jonathan >> >>
Jonathan, Here is an example of a connection string to connect to an Access mdb database file named "myDB.mdb": Dim cn As New OleDbConnection(("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=myDB.mdb;")) Kerry Moorman [quoted text, click to view] "Jonathan Wood" wrote: > > Really, I can use an Access database without Access? Where would I find out > about this? Is a connection string still involved? What does it look like? > That's what I'm trying to find out. > > > Jonathan >
Kerry, [quoted text, click to view] > You could work with a non-server DBMS such as Access through ADO.Net > without > needing Access installed.
Really, I can use an Access database without Access? Where would I find out about this? Is a connection string still involved? What does it look like? That's what I'm trying to find out. [quoted text, click to view] > But for any of the server-type DBMSs like SQL Server, Oracle, DB2, etc., > you > need the DBMS installed and then your ADO.Net code "talks to" the server > DBMS.
Yes, I understand. If I want to access some sort of server software then that software must be installed. The only purpose of this thread is to explorer what options I have that don't involve these. Jonathan
Do not beconfused with application (you developed), application development framework (.NET Framework) and various type s of data source, be it server-base database system (MySQL, SQL Server, Oracle), or file base database system (Jet database, *.mdb/*.mde, or you can loosely call it Access database), or even a flat text file. Server based database itself is complicated enough to learn and use. Most programming starter starts with Access database (Jet database), since it is file based. To access jet database, you do not need Access installed, you only need Jet engine available, which comes in all Windows OS, at least since Win95 (you may need to download latest Jet SP (SP8) if you use older Windows OS, though). When you do ADO.NET app, you could then use a *.mdb file as data source (using OleDb namespace in ADO.NET), you could even use Excel sheet (*.xls) or comma delimited flat text as data source. In this case, yes you do not need anything else installed besides .NET. However, if you need truy database system, then you have make your choice of database system products, which most likely is not a part of either Windows or .NET, and most likely, it cost money to buy and cost time to learn and use. In this case, you app might be a very small part of the entire system and cost the least to build. These days, server based database find their places in most software development, while file based database is mostly used on desktop app for single user settings (if the db is a decent product, such as Jet/Access database, it may still be used in multiple users/LAN settings, but certainly not good choice for web applications). If you are really geared to programming, learning/using database server is certainly a basic. In MS platform, SQL Server is the mostly used product, that is why all ..NET/ADO.NET example use it and it comes with VS (but it is NOT PART of .NET framework). [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:%23wplJIV9HHA.484@TK2MSFTNGP06.phx.gbl... > Is it assumed I know what MDAC is? So, you're saying the OleDbConnection > string posted below may not work on all computers with the .NET framework > installed? > > Jonathan > > "Miha Markic" <miha at rthand com> wrote in message > news:OeOxt7U9HHA.5948@TK2MSFTNGP04.phx.gbl... >> Jonathan, >> >> Take note that JET driver (Access) is installed with MDAC (which is >> installed along .net, too). >> However, JET driver was pulled out of MDAC for a while (now it is back >> in) and thus it isn't guaranteed to be available. I don't know which >> versions are missing the JET out of my head. >> -- >> Miha Markic [MVP C#, INETA Country Leader for Slovenia] >> RightHand .NET consulting & development www.rthand.com >> Blog: http://cs.rthand.com/blogs/blog_with_righthand/ >> >> "Jonathan Wood" <jwood@softcircuits.com> wrote in message >> news:OQjwB4U9HHA.484@TK2MSFTNGP06.phx.gbl... >>> If that works with no additional software other than the .NET framework, >>> that is exactly what I'm looking for. >>> >>> I'll check it out. Thanks. >>> >>> Jonathan >>> >>> "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in >>> message news:6F761E34-14C8-48C3-87F7-1FC8209067D1@microsoft.com... >>>> Jonathan, >>>> >>>> Here is an example of a connection string to connect to an Access mdb >>>> database file named "myDB.mdb": >>>> >>>> Dim cn As New OleDbConnection(("Provider=Microsoft.Jet.OLEDB.4.0;Data >>>> Source=myDB.mdb;")) >>>> >>>> Kerry Moorman >>>> >>>> >>>> "Jonathan Wood" wrote: >>>> >>>>> >>>>> Really, I can use an Access database without Access? Where would I >>>>> find out >>>>> about this? Is a connection string still involved? What does it look >>>>> like? >>>>> That's what I'm trying to find out. >>>>> >>>>> >>>>> Jonathan >>>>> >>>>> >>> >> >
If that works with no additional software other than the .NET framework, that is exactly what I'm looking for. I'll check it out. Thanks. Jonathan [quoted text, click to view] "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in message news:6F761E34-14C8-48C3-87F7-1FC8209067D1@microsoft.com... > Jonathan, > > Here is an example of a connection string to connect to an Access mdb > database file named "myDB.mdb": > > Dim cn As New OleDbConnection(("Provider=Microsoft.Jet.OLEDB.4.0;Data > Source=myDB.mdb;")) > > Kerry Moorman > > > "Jonathan Wood" wrote: > >> >> Really, I can use an Access database without Access? Where would I find >> out >> about this? Is a connection string still involved? What does it look >> like? >> That's what I'm trying to find out. >> >> >> Jonathan >> >>
Is it assumed I know what MDAC is? So, you're saying the OleDbConnection string posted below may not work on all computers with the .NET framework installed? Jonathan [quoted text, click to view] "Miha Markic" <miha at rthand com> wrote in message news:OeOxt7U9HHA.5948@TK2MSFTNGP04.phx.gbl... > Jonathan, > > Take note that JET driver (Access) is installed with MDAC (which is > installed along .net, too). > However, JET driver was pulled out of MDAC for a while (now it is back in) > and thus it isn't guaranteed to be available. I don't know which versions > are missing the JET out of my head. > -- > Miha Markic [MVP C#, INETA Country Leader for Slovenia] > RightHand .NET consulting & development www.rthand.com > Blog: http://cs.rthand.com/blogs/blog_with_righthand/ > > "Jonathan Wood" <jwood@softcircuits.com> wrote in message > news:OQjwB4U9HHA.484@TK2MSFTNGP06.phx.gbl... >> If that works with no additional software other than the .NET framework, >> that is exactly what I'm looking for. >> >> I'll check it out. Thanks. >> >> Jonathan >> >> "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in message >> news:6F761E34-14C8-48C3-87F7-1FC8209067D1@microsoft.com... >>> Jonathan, >>> >>> Here is an example of a connection string to connect to an Access mdb >>> database file named "myDB.mdb": >>> >>> Dim cn As New OleDbConnection(("Provider=Microsoft.Jet.OLEDB.4.0;Data >>> Source=myDB.mdb;")) >>> >>> Kerry Moorman >>> >>> >>> "Jonathan Wood" wrote: >>> >>>> >>>> Really, I can use an Access database without Access? Where would I find >>>> out >>>> about this? Is a connection string still involved? What does it look >>>> like? >>>> That's what I'm trying to find out. >>>> >>>> >>>> Jonathan >>>> >>>> >> >
Miha, [quoted text, click to view] >> Is it assumed I know what MDAC is? So, you're saying the OleDbConnection >> string posted below may not work on all computers with the .NET framework >> installed? > > Yes, it depends on the MDAC version installed (somebody might install a > different version of MDAC regardless of version installed with .net). > BTW here you'll find connection string definitions: > www.connectionstrings.com I wasn't sure what I was looking for at that link. The bottom line for me is that I want my application to install painlessly on customers' computers. When writing a Windows .NET application, I can write my own code to save data to disk, or I can use the .NET database stuff. If the database stuff either requires additional installations or is not guaranteed to work on all computers with .NET, then I'll avoid it. It sounds like you're saying it may not work on all computers with .NET, so I should avoid the database routines for my desktop applications. Thanks. Jonathan
Norman, [quoted text, click to view] > Do not beconfused with application (you developed), application > development framework (.NET Framework) and various type s of data source, > be it server-base database system (MySQL, SQL Server, Oracle), or file > base database system (Jet database, *.mdb/*.mde, or you can loosely call > it Access database), or even a flat text file.
I didn't think I was confused on that issue. [quoted text, click to view] > When you do ADO.NET app, you could then use a *.mdb file as data source > (using OleDb namespace in ADO.NET), you could even use Excel sheet (*.xls) > or comma delimited flat text as data source. In this case, yes you do not > need anything else installed besides .NET.
Well, that's the exact info I'm after. However, it's a little confusing because of Miha's comments that the "JET driver is installed with MDAC" and that driver was "pulled out of MDAC for a while." This seemed to suggest to me that, on some systems with .NET, additional drivers may be required to use MDB files. [quoted text, click to view] > However, if you need truy database system, then you have make your choice > of database system products, which most likely is not a part of either > Windows or .NET, and most likely, it cost money to buy and cost time to > learn and use. In this case, you app might be a very small part of the > entire system and cost the least to build.
That's the approach I'll take for Web development. Not for desktop applications. Thanks. Jonathan
[quoted text, click to view] "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in message news:7623F44B-23B4-4D31-8312-09552659487E@microsoft.com... > Jonathan, > > If you want to write a program that works with SQL Server data then you > must > go through SQL Server. > > There is no way to access SQL Server data with ADO.Net (or any other > technology) without SQL Server.
You could write and read directly from its files ;-). Just kidding -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/
Miha, [quoted text, click to view] > You have to understand that ado.net is *not a database engine*. It is an > abstraction layer *over database stuff*. No database engine is part of > .net. > It happens that jet is a part of MDAC and MDAC is installed with .net. > But let's get back to your problem. You want a database without need to > worry. > I would recomend SQL Server 2005 CE. > http://www.microsoft.com/sql/editions/compact/default.mspx > It is a subset of real SQL Server, it is free and it is deployed by simpy > including an assembly or two with your app (I haven't worked with it > yet) - no deployment hassles at all! I seem to be having a horrible time communicating for reasons I just cannot fathom. [quoted text, click to view] >>>> No additional software beyond my application and the .NET frameworks. >>>> <<<<
That's what I want. And if I have to write routines from scratch to save and load my data from disk, that's exactly what I'll do. (I've done it plenty of times in the past.) SQL Server 2005 CE would be additional software. Jonathan
Miha, [quoted text, click to view] >> That's what I want. And if I have to write routines from scratch to save >> and load my data from disk, that's exactly what I'll do. (I've done it >> plenty of times in the past.) > > Perhaps you should stop saying it in different ways:
If I find a way that seems to work, I'll just use that one. [quoted text, click to view] > "The bottom line for me is that I want my application to install > painlessly > on customers' computers. When writing a Windows .NET application, I can > write my own code to save data to disk, or I can use the .NET database > stuff. If the database stuff either requires additional installations or > is > not guaranteed to work on all computers with .NET, then I'll avoid it."
Couldn't have said it better myself. :-) [quoted text, click to view] > I really don't see any problem with using SQL Server 2005 CE as it doesn't > require any installation at all beside copying a couple of files along > your application. > But then again, if it is copying a couple of files too much for you, go > ahead, write some code and copy the file containing your code.
That would definitely be a plus if it was just a couple of extra files that we are free to distribute with our programs. But the size becomes an important issue then. I'm writing shareware that the user must download. If I add a MB or two, that could have a major impact on the success of the app. My experience tells me that most people in these forums look at this and say "a couple of MB isn't a big deal" or maybe "so they have to wait a bit longer." But this market consists of non-technical users and each user that doesn't download and install it is a potential sale lost. Maybe I can find out the rules on distribution for SQL Server 2005 CE, if all that's needed is copying the files, and the sizes of those files. I'd be surprised if it would really be painless for the end user but I could certainly be wrong. Thanks. Jonathan
If you are to do web application, go with server based database. Jet database (Access) can be used in web app in certain extent, but not recommended. So, if you r web app needs database, learning SQL Server is the easiest. As for deploy your ADO.NET web app, you may or may not need to deploy/install SQL Server on your web app host, depending on the host services. If a host hosts thousands of web apps, all of which use SQL Server, it is unlikely the host install thousands SQL Server instances on its web server(s). There may be only one or two SQL Server instances, each have hundreds or thousands database attached. In this case, you deploy your database to the server, not SQL Server. There is many ways to deploy your SQL Server database to an existing SQL Server. So, if your web app uses database (sever based, such as SQL Server), you do not need anything to run your app, as long as you can getthe database setup correctly, which is not part of .NET and depending what type of database you use. Jet Engine comes with all Windows OS. Before MDAC2.6, each new version MDAC includes Jet Engine update. After MDAC2.6 (latest is MDAC2.8), Jet Engine update is not included in MDAC any more, but Jet Engine still exists in your Windows OS, you just need to download its latest update seperately (SP8, available in year2001 or 2). If you use Vista, Win2003SP2, or have your Windows Update active, you probably has the latest updated Jet Engine any way. Even you use older Windows OS, it is for sure you have Jet Engine available, just may not be in its latest update. [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:O1VoGeW9HHA.1208@TK2MSFTNGP05.phx.gbl... > Norman, > >> Do not beconfused with application (you developed), application >> development framework (.NET Framework) and various type s of data source, >> be it server-base database system (MySQL, SQL Server, Oracle), or file >> base database system (Jet database, *.mdb/*.mde, or you can loosely call >> it Access database), or even a flat text file. > > I didn't think I was confused on that issue. > >> When you do ADO.NET app, you could then use a *.mdb file as data source >> (using OleDb namespace in ADO.NET), you could even use Excel sheet >> (*.xls) or comma delimited flat text as data source. In this case, yes >> you do not need anything else installed besides .NET. > > Well, that's the exact info I'm after. However, it's a little confusing > because of Miha's comments that the "JET driver is installed with MDAC" > and that driver was "pulled out of MDAC for a while." This seemed to > suggest to me that, on some systems with .NET, additional drivers may be > required to use MDB files. > >> However, if you need truy database system, then you have make your choice >> of database system products, which most likely is not a part of either >> Windows or .NET, and most likely, it cost money to buy and cost time to >> learn and use. In this case, you app might be a very small part of the >> entire system and cost the least to build. > > That's the approach I'll take for Web development. Not for desktop > applications. > > Thanks. > > Jonathan >
Jonathan, Take note that JET driver (Access) is installed with MDAC (which is installed along .net, too). However, JET driver was pulled out of MDAC for a while (now it is back in) and thus it isn't guaranteed to be available. I don't know which versions are missing the JET out of my head. -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:OQjwB4U9HHA.484@TK2MSFTNGP06.phx.gbl... > If that works with no additional software other than the .NET framework, > that is exactly what I'm looking for. > > I'll check it out. Thanks. > > Jonathan > > "Kerry Moorman" <KerryMoorman@discussions.microsoft.com> wrote in message > news:6F761E34-14C8-48C3-87F7-1FC8209067D1@microsoft.com... >> Jonathan, >> >> Here is an example of a connection string to connect to an Access mdb >> database file named "myDB.mdb": >> >> Dim cn As New OleDbConnection(("Provider=Microsoft.Jet.OLEDB.4.0;Data >> Source=myDB.mdb;")) >> >> Kerry Moorman >> >> >> "Jonathan Wood" wrote: >> >>> >>> Really, I can use an Access database without Access? Where would I find >>> out >>> about this? Is a connection string still involved? What does it look >>> like? >>> That's what I'm trying to find out. >>> >>> >>> Jonathan >>> >>> >
[quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:%23wplJIV9HHA.484@TK2MSFTNGP06.phx.gbl... > Is it assumed I know what MDAC is? So, you're saying the OleDbConnection > string posted below may not work on all computers with the .NET framework > installed?
Yes, it depends on the MDAC version installed (somebody might install a different version of MDAC regardless of version installed with .net). BTW here you'll find connection string definitions: www.connectionstrings.com -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/
Norman, [quoted text, click to view] > If you are to do web application, go with server based database. Jet > database (Access) can be used in web app in certain extent, but not > recommended. So, if you r web app needs database, learning SQL Server is > the easiest.
Installation is a non-issue for Web applications. As I indicated in my original post (and several thereafter), this is related to a Windows application. If I'm still being unclear, that means a desktop application to me. [quoted text, click to view] > As for deploy your ADO.NET web app, you may or may not need to > deploy/install SQL Server on your web app host, depending on the host > services.
Again, deployment is a non-issue for Web apps. I can have someone install it or do it myself. If I'm distributing desktop apps to non-technical users, then I need to worry about what libraries are needed. [quoted text, click to view] > So, if your web app uses database (sever based, such as SQL Server), you > do not need anything to run your app, as long as you can getthe database > setup correctly, which is not part of .NET and depending what type of > database you use.
It's not a Web app. Deployment is absolutely not an issue for Web apps. [quoted text, click to view] > Jet Engine comes with all Windows OS. Before MDAC2.6, each new version > MDAC includes Jet Engine update. After MDAC2.6 (latest is MDAC2.8), Jet > Engine update is not included in MDAC any more, but Jet Engine still > exists in your Windows OS, you just need to download its latest update > seperately (SP8, available in year2001 or 2). If you use Vista, > Win2003SP2, or have your Windows Update active, you probably has the > latest updated Jet Engine any way. Even you use older Windows OS, it is > for sure you have Jet Engine available, just may not be in its latest > update.
Asking my end-users, many of whom are not technical, to download and install additional software/drivers is out of the question. So it sounds like I cannot take this approach. Jonathan
Cor, [quoted text, click to view] > By the way, I don't go in discussion with you, nobody forces you to use > dotNet, SQL server or whatever who is active in this newsgroup, including > Microsoft MSFT's.
I'm sorry, I'm having a hard time understanding what you mean here. You won't have a discussion with me because no one forces me to use something? I just don't understand that, or how it relates to anything I've said. Jonathan
BTW, that link is close to what I want. Unfortunately, based on the comments here, I cannot assume the JET library will be available on all of my customers machines. That's a concern for me for the reasons I've explained in this thread. Thanks. Jonathan [quoted text, click to view] "Cor Ligthert[MVP]" <notmyfirstname@planet.nl> wrote in message news:BAFE6B55-E17C-4184-BDFD-8CCE227E7998@microsoft.com... > Jonathan, > > If you want to work without sold Databases, than build them yourself. In > the old days there were never databases used, just flat text files. > > It is a little bit very much more work, however not without problems. If > you don't want that, than just follow the advices in this thread. I don't > use all for a long time Access anymore. If it works on Vista you can just > try yourself this tip. > > http://www.vb-tips.com/CreateMDB.aspx > > By the way, I don't go in discussion with you, nobody forces you to use > dotNet, SQL server or whatever who is active in this newsgroup, including > Microsoft MSFT's. > > Cor > "Jonathan Wood" <jwood@softcircuits.com> schreef in bericht > news:%23QB8qSY9HHA.4880@TK2MSFTNGP03.phx.gbl... >> Miha, >> >>>> That's what I want. And if I have to write routines from scratch to >>>> save and load my data from disk, that's exactly what I'll do. (I've >>>> done it plenty of times in the past.) >>> >>> Perhaps you should stop saying it in different ways: >> >> If I find a way that seems to work, I'll just use that one. >> >>> "The bottom line for me is that I want my application to install >>> painlessly >>> on customers' computers. When writing a Windows .NET application, I can >>> write my own code to save data to disk, or I can use the .NET database >>> stuff. If the database stuff either requires additional installations or >>> is >>> not guaranteed to work on all computers with .NET, then I'll avoid it." >> >> Couldn't have said it better myself. :-) >> >>> I really don't see any problem with using SQL Server 2005 CE as it >>> doesn't require any installation at all beside copying a couple of files >>> along your application. >>> But then again, if it is copying a couple of files too much for you, go >>> ahead, write some code and copy the file containing your code. >> >> That would definitely be a plus if it was just a couple of extra files >> that we are free to distribute with our programs. But the size becomes an >> important issue then. I'm writing shareware that the user must download. >> If I add a MB or two, that could have a major impact on the success of >> the app. My experience tells me that most people in these forums look at >> this and say "a couple of MB isn't a big deal" or maybe "so they have to >> wait a bit longer." But this market consists of non-technical users and >> each user that doesn't download and install it is a potential sale lost. >> >> Maybe I can find out the rules on distribution for SQL Server 2005 CE, if >> all that's needed is copying the files, and the sizes of those files. I'd >> be surprised if it would really be painless for the end user but I could >> certainly be wrong. >> >> Thanks. >> >> Jonathan >> >
[quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:uE7igaW9HHA.4584@TK2MSFTNGP03.phx.gbl... > Miha, > >>> Is it assumed I know what MDAC is? So, you're saying the OleDbConnection >>> string posted below may not work on all computers with the .NET >>> framework installed? >> >> Yes, it depends on the MDAC version installed (somebody might install a >> different version of MDAC regardless of version installed with .net). >> BTW here you'll find connection string definitions: >> www.connectionstrings.com > > I wasn't sure what I was looking for at that link. > > The bottom line for me is that I want my application to install painlessly > on customers' computers. When writing a Windows .NET application, I can > write my own code to save data to disk, or I can use the .NET database > stuff. If the database stuff either requires additional installations or > is not guaranteed to work on all computers with .NET, then I'll avoid it. > > It sounds like you're saying it may not work on all computers with .NET, > so I should avoid the database routines for my desktop applications. You have to understand that ado.net is *not a database engine*. It is an abstraction layer *over database stuff*. No database engine is part of .net. It happens that jet is a part of MDAC and MDAC is installed with .net. But let's get back to your problem. You want a database without need to worry. I would recomend SQL Server 2005 CE. http://www.microsoft.com/sql/editions/compact/default.mspx It is a subset of real SQL Server, it is free and it is deployed by simpy including an assembly or two with your app (I haven't worked with it yet) - no deployment hassles at all! -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/
[quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:euXjsAY9HHA.1484@TK2MSFTNGP06.phx.gbl... > Miha, > >> You have to understand that ado.net is *not a database engine*. It is an >> abstraction layer *over database stuff*. No database engine is part of >> .net. >> It happens that jet is a part of MDAC and MDAC is installed with .net. >> But let's get back to your problem. You want a database without need to >> worry. >> I would recomend SQL Server 2005 CE. >> http://www.microsoft.com/sql/editions/compact/default.mspx >> It is a subset of real SQL Server, it is free and it is deployed by simpy >> including an assembly or two with your app (I haven't worked with it >> yet) - no deployment hassles at all! > > I seem to be having a horrible time communicating for reasons I just > cannot fathom. > >>>>> No additional software beyond my application and the .NET frameworks. >>>>> <<<< > > That's what I want. And if I have to write routines from scratch to save > and load my data from disk, that's exactly what I'll do. (I've done it > plenty of times in the past.) Perhaps you should stop saying it in different ways: "The bottom line for me is that I want my application to install painlessly on customers' computers. When writing a Windows .NET application, I can write my own code to save data to disk, or I can use the .NET database stuff. If the database stuff either requires additional installations or is not guaranteed to work on all computers with .NET, then I'll avoid it." I really don't see any problem with using SQL Server 2005 CE as it doesn't require any installation at all beside copying a couple of files along your application. But then again, if it is copying a couple of files too much for you, go ahead, write some code and copy the file containing your code. -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/
[quoted text, click to view] > Couldn't have said it better myself. :-)
lol. [quoted text, click to view] > >> I really don't see any problem with using SQL Server 2005 CE as it >> doesn't require any installation at all beside copying a couple of files >> along your application. >> But then again, if it is copying a couple of files too much for you, go >> ahead, write some code and copy the file containing your code. > > That would definitely be a plus if it was just a couple of extra files > that we are free to distribute with our programs. But the size becomes an > important issue then. I'm writing shareware that the user must download. > If I add a MB or two, that could have a major impact on the success of the > app. My experience tells me that most people in these forums look at this > and say "a couple of MB isn't a big deal" or maybe "so they have to wait a > bit longer." But this market consists of non-technical users and each user > that doesn't download and install it is a potential sale lost.
You didn't mention the size problem before. Anyway, either I forgot or you didn't tell, why do you need a database at all? If you are dealing with small amount of data then you might use another approach. [quoted text, click to view] > > Maybe I can find out the rules on distribution for SQL Server 2005 CE, if > all that's needed is copying the files, and the sizes of those files. I'd > be surprised if it would really be painless for the end user but I could > certainly be wrong.
It is supposed to be completely transparent to user. -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/
[quoted text, click to view] > Asking my end-users, many of whom are not technical, to download and > install > additional software/drivers is out of the question. So it sounds like I > cannot take this approach.
A well build installer cuild download & install required components automatically. Actually, a .net app installation can download framework automatically (if not present on the machine). That said am I not saying that you should go this route with your application - a jet-less approach is better. -- Miha Markic [MVP C#, INETA Country Leader for Slovenia] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/
Jonathan, If you want to work without sold Databases, than build them yourself. In the old days there were never databases used, just flat text files. It is a little bit very much more work, however not without problems. If you don't want that, than just follow the advices in this thread. I don't use all for a long time Access anymore. If it works on Vista you can just try yourself this tip. http://www.vb-tips.com/CreateMDB.aspx By the way, I don't go in discussion with you, nobody forces you to use dotNet, SQL server or whatever who is active in this newsgroup, including Microsoft MSFT's. Cor "Jonathan Wood" <jwood@softcircuits.com> schreef in bericht news:%23QB8qSY9HHA.4880@TK2MSFTNGP03.phx.gbl... [quoted text, click to view] > Miha, > >>> That's what I want. And if I have to write routines from scratch to save >>> and load my data from disk, that's exactly what I'll do. (I've done it >>> plenty of times in the past.) >> >> Perhaps you should stop saying it in different ways: > > If I find a way that seems to work, I'll just use that one. > >> "The bottom line for me is that I want my application to install >> painlessly >> on customers' computers. When writing a Windows .NET application, I can >> write my own code to save data to disk, or I can use the .NET database >> stuff. If the database stuff either requires additional installations or >> is >> not guaranteed to work on all computers with .NET, then I'll avoid it." > > Couldn't have said it better myself. :-) > >> I really don't see any problem with using SQL Server 2005 CE as it >> doesn't require any installation at all beside copying a couple of files >> along your application. >> But then again, if it is copying a couple of files too much for you, go >> ahead, write some code and copy the file containing your code. > > That would definitely be a plus if it was just a couple of extra files > that we are free to distribute with our programs. But the size becomes an > important issue then. I'm writing shareware that the user must download. > If I add a MB or two, that could have a major impact on the success of the > app. My experience tells me that most people in these forums look at this > and say "a couple of MB isn't a big deal" or maybe "so they have to wait a > bit longer." But this market consists of non-technical users and each user > that doesn't download and install it is a potential sale lost. > > Maybe I can find out the rules on distribution for SQL Server 2005 CE, if > all that's needed is copying the files, and the sizes of those files. I'd > be surprised if it would really be painless for the end user but I could > certainly be wrong. > > Thanks. > > Jonathan >
Miha, [quoted text, click to view] > You didn't mention the size problem before. Anyway, either I forgot or you > didn't tell, why do you need a database at all? > If you are dealing with small amount of data then you might use another > approach.
Exactly. That's what I'm saying: I'm trying to decide if I should write the data to disk directly or use a database. In fact, the previous version of this software (written in C++) did not use a database engine. However, due to the requirements, the code that saved the data was pretty sophisticated, and the new version needs to be even more so. If .NET included database libraries, I was just looking into if it made sense to use them instead. Right now, it looks like the answer is "no." [quoted text, click to view] >> Maybe I can find out the rules on distribution for SQL Server 2005 CE, if >> all that's needed is copying the files, and the sizes of those files. I'd >> be surprised if it would really be painless for the end user but I could >> certainly be wrong. > > It is supposed to be completely transparent to user.
Looks like the distributables are about 1MB. I'm not sure. Thanks. Jonathan
Jonathan. We can tell that you don't have a lot of experience with .NET. If you expect to create a commercially viable application you it's unwise to choose a data access paradigm simply by asking questions in a public newsgroup--it's like cruising the web to learn how to do an appendectomy on the kitchen table. The choice of a database engine (if you use one) needs to consider cost per installation, deployment strategy, stability, query and update performance, developer productivity, ease of use, and not least of all security. I (and I expect most here would agree) think you should take a course, read a book (or two) or otherwise do a bit more study before you venture off and try to build an application that will handle data for paying customers. Case in point: The MDAC stack and JET have been mentioned here a number of times. Unless I missed it, nowhere was it mentioned that Microsoft is doing what it can to get developers to stop using JET--its architecture has security, reliability and performance problems. While widely (too widely) used, IMHO, JET is a dead-end technology. If you are just learning (as it appears you are), I suggest investing in newer, more stable technology that has a future and is better suited to .NET. JET does not have a native managed provider--you must access it via a one-size-fits-all OLE DB interface. In contrast, SQL Server Compact Edition (as I recommended before) has been adapted for Windows Forms (desktop applications) and .NET--it does have a native .NET interface. It is one of the free JET replacements I have recommended many times. SQLCe is a lightweight single-user engine which make it ideal for many applications (especially Windows desktop applications) as the one you describe. For multi-user requirements, I recommend SQL Server Express or better. You can start with the Express edition (free) and grow into the other (paid license) editions when your application needs require more features and scalability. I think you would benefit from reading my eBook on SQL Server Compact edition or my Hitchhiker's Guide. And yes, there are other books out there on data access application design but most are not written for those just getting started with .NET. Mine is. I hope this helps. -- ____________________________________ William (Bill) Vaughn Author, Mentor, Consultant, Dad, Grandpa Microsoft MVP INETA Speaker www.betav.com www.betav.com/blog/billva Please reply only to the newsgroup so that others can benefit. This posting is provided "AS IS" with no warranties, and confers no rights. __________________________________ Visit www.hitchhikerguides.net to get more information on my latest book: Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition) and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook) ----------------------------------------------------------------------------------------------------------------------- [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:el%23rNua9HHA.2752@TK2MSFTNGP06.phx.gbl... > Norman, > >> If you are to do web application, go with server based database. Jet >> database (Access) can be used in web app in certain extent, but not >> recommended. So, if you r web app needs database, learning SQL Server is >> the easiest. > > Installation is a non-issue for Web applications. As I indicated in my > original post (and several thereafter), this is related to a Windows > application. If I'm still being unclear, that means a desktop application > to me. > >> As for deploy your ADO.NET web app, you may or may not need to >> deploy/install SQL Server on your web app host, depending on the host >> services. > > Again, deployment is a non-issue for Web apps. I can have someone install > it or do it myself. If I'm distributing desktop apps to non-technical > users, then I need to worry about what libraries are needed. > >> So, if your web app uses database (sever based, such as SQL Server), you >> do not need anything to run your app, as long as you can getthe database >> setup correctly, which is not part of .NET and depending what type of >> database you use. > > It's not a Web app. Deployment is absolutely not an issue for Web apps. > >> Jet Engine comes with all Windows OS. Before MDAC2.6, each new version >> MDAC includes Jet Engine update. After MDAC2.6 (latest is MDAC2.8), Jet >> Engine update is not included in MDAC any more, but Jet Engine still >> exists in your Windows OS, you just need to download its latest update >> seperately (SP8, available in year2001 or 2). If you use Vista, >> Win2003SP2, or have your Windows Update active, you probably has the >> latest updated Jet Engine any way. Even you use older Windows OS, it is >> for sure you have Jet Engine available, just may not be in its latest >> update. > > Asking my end-users, many of whom are not technical, to download and > install additional software/drivers is out of the question. So it sounds > like I cannot take this approach. > > Jonathan >
William, [quoted text, click to view] > We can tell that you don't have a lot of experience with .NET. If you > expect to create a commercially viable application you it's unwise to > choose a data access paradigm simply by asking questions in a public > newsgroup--it's like cruising the web to learn how to do an appendectomy > on the kitchen table.
Yes, and this has come across in many of your posts to me. Frankly, I don't get it. I'm working through a stack of books that involves many technologies and SQL is just one of them. It is not easy, and on some issues I just want to know which direction I should be going. If you have an issue with that, you can safely ignore my posts. But, as I've mentioned before, I've been helping people in various programming newsgroups for many years, and I've never avoided helping someone because it seemed like they were just getting started. [quoted text, click to view] > Case in point: The MDAC stack and JET have been mentioned here a number > of times. Unless I missed it, nowhere was it mentioned that Microsoft is > doing what it can to get developers to stop using JET--its architecture > has security, reliability and performance problems. While widely (too > widely) used, IMHO, JET is a dead-end technology. If you are just learning > (as it appears you are), I suggest investing in newer, more stable > technology that has a future and is better suited to .NET.
You lost me on the comment about MS trying to get developers to stop using JET. I don't recall anything about that. But my plan is to use ADO.NET--for certain tasks. But for the purpose of this particular thread, using no database library at all is an option, in fact, it's the option I used in the previous version of the software in question. All I'm asking are high-level questions to try and determine if a database engine would meet my particular needs. If I can determine that, then I can better determine which books I should read next. [quoted text, click to view] > JET does not have a native managed provider--you must access it via a > one-size-fits-all OLE DB interface. In contrast, SQL Server Compact > Edition (as I recommended before) has been adapted for Windows Forms > (desktop applications) and .NET--it does have a native .NET interface. It > is one of the free JET replacements I have recommended many times. SQLCe > is a lightweight single-user engine which make it ideal for many > applications (especially Windows desktop applications) as the one you > describe. For multi-user requirements, I recommend SQL Server Express or > better. You can start with the Express edition (free) and grow into the > other (paid license) editions when your application needs require more > features and scalability.
I'm weighing the pros and cons of SQL Server Compact Edition. Right now, my main concern is that it requires an additional 1MB in my distributables and that is a concern. Perhaps, I will try and find your eBook on it to further clarify my thinking. Thanks for that. [quoted text, click to view] > I think you would benefit from reading my eBook on SQL Server Compact > edition or my Hitchhiker's Guide. And yes, there are other books out there > on data access application design but most are not written for those just > getting started with .NET. Mine is.
Yes, and I've purchased your book. But I've got other books ahead of it and, when I'm done with those, I'll try and make a determination if your book makes sense for me. Hopefully, by then, I'll have a better idea of the direction I'm going in some of these fundamental issues. Jonathan
Thanks for the input but I don't really understand. Being part of VS.NET does not help me when it comes to distributing my apps. And that really is the main point of this thread. Please let me know if I'm missing your point. Jonathan [quoted text, click to view] "Cor Ligthert[MVP]" <notmyfirstname@planet.nl> wrote in message news:C9BF59C7-D0E5-437E-B86E-9EC2F7D045D7@microsoft.com... > The answer is Yes, as SQL server express is a complete part of the > software supplied by Visual Studio Net. It is as well free for other > people. > > Cor > > "Jonathan Wood" <jwood@softcircuits.com> schreef in bericht > news:%236DD4bg9HHA.5164@TK2MSFTNGP05.phx.gbl... >> Miha, >> >>> You didn't mention the size problem before. Anyway, either I forgot or >>> you didn't tell, why do you need a database at all? >>> If you are dealing with small amount of data then you might use another >>> approach. >> >> Exactly. That's what I'm saying: I'm trying to decide if I should write >> the data to disk directly or use a database. In fact, the previous >> version of this software (written in C++) did not use a database engine. >> >> However, due to the requirements, the code that saved the data was pretty >> sophisticated, and the new version needs to be even more so. If .NET >> included database libraries, I was just looking into if it made sense to >> use them instead. >> >> Right now, it looks like the answer is "no." >> >>>> Maybe I can find out the rules on distribution for SQL Server 2005 CE, >>>> if all that's needed is copying the files, and the sizes of those >>>> files. I'd be surprised if it would really be painless for the end user >>>> but I could certainly be wrong. >>> >>> It is supposed to be completely transparent to user. >> >> Looks like the distributables are about 1MB. I'm not sure. >> >> Thanks. >> >> Jonathan >> >
The answer is Yes, as SQL server express is a complete part of the software supplied by Visual Studio Net. It is as well free for other people. Cor "Jonathan Wood" <jwood@softcircuits.com> schreef in bericht news:%236DD4bg9HHA.5164@TK2MSFTNGP05.phx.gbl... [quoted text, click to view] > Miha, > >> You didn't mention the size problem before. Anyway, either I forgot or >> you didn't tell, why do you need a database at all? >> If you are dealing with small amount of data then you might use another >> approach. > > Exactly. That's what I'm saying: I'm trying to decide if I should write > the data to disk directly or use a database. In fact, the previous version > of this software (written in C++) did not use a database engine. > > However, due to the requirements, the code that saved the data was pretty > sophisticated, and the new version needs to be even more so. If .NET > included database libraries, I was just looking into if it made sense to > use them instead. > > Right now, it looks like the answer is "no." > >>> Maybe I can find out the rules on distribution for SQL Server 2005 CE, >>> if all that's needed is copying the files, and the sizes of those files. >>> I'd be surprised if it would really be painless for the end user but I >>> could certainly be wrong. >> >> It is supposed to be completely transparent to user. > > Looks like the distributables are about 1MB. I'm not sure. > > Thanks. > > Jonathan >
Okay, AFA SQLCe, consider that the functionality you get for that 1MB database engine might be just what you need. Of course, you might need far less but 1MB is a drop in the bucket by today's standards. -- ____________________________________ William (Bill) Vaughn Author, Mentor, Consultant, Dad, Grandpa Microsoft MVP INETA Speaker www.betav.com www.betav.com/blog/billva Please reply only to the newsgroup so that others can benefit. This posting is provided "AS IS" with no warranties, and confers no rights. __________________________________ Visit www.hitchhikerguides.net to get more information on my latest book: Hitchhiker's Guide to Visual Studio and SQL Server (7th Edition) and Hitchhiker's Guide to SQL Server 2005 Compact Edition (EBook) ----------------------------------------------------------------------------------------------------------------------- [quoted text, click to view] "Jonathan Wood" <jwood@softcircuits.com> wrote in message news:O3OOiQm9HHA.600@TK2MSFTNGP05.phx.gbl... > William, > >> We can tell that you don't have a lot of experience with .NET. If you >> expect to create a commercially viable application you it's unwise to >> choose a data access paradigm simply by asking questions in a public >> newsgroup--it's like cruising the web to learn how to do an appendectomy >> on the kitchen table. > > Yes, and this has come across in many of your posts to me. Frankly, I > don't get it. I'm working through a stack of books that involves many > technologies and SQL is just one of them. It is not easy, and on some > issues I just want to know which direction I should be going. If you have > an issue with that, you can safely ignore my posts. But, as I've mentioned > before, I've been helping people in various programming newsgroups for > many years, and I've never avoided helping someone because it seemed like > they were just getting started. > >> Case in point: The MDAC stack and JET have been mentioned here a >> number of times. Unless I missed it, nowhere was it mentioned that >> Microsoft is doing what it can to get developers to stop using JET--its >> architecture has security, reliability and performance problems. While >> widely (too widely) used, IMHO, JET is a dead-end technology. If you are >> just learning (as it appears you are), I suggest investing in newer, more >> stable technology that has a future and is better suited to .NET. > > You lost me on the comment about MS trying to get developers to stop using > JET. I don't recall anything about that. > > But my plan is to use ADO.NET--for certain tasks. But for the purpose of > this particular thread, using no database library at all is an option, in > fact, it's the option I used in the previous version of the software in > question. All I'm asking are high-level questions to try and determine if > a database engine would meet my particular needs. If I can determine that, > then I can better determine which books I should read next. > >> JET does not have a native managed provider--you must access it via a >> one-size-fits-all OLE DB interface. In contrast, SQL Server Compact >> Edition (as I recommended before) has been adapted for Windows Forms >> (desktop applications) and .NET--it does have a native .NET interface. It >> is one of the free JET replacements I have recommended many times. SQLCe >> is a lightweight single-user engine which make it ideal for many >> applications (especially Windows desktop applications) as the one you >> describe. For multi-user requirements, I recommend SQL Server Express or >> better. You can start with the Express edition (free) and grow into the >> other (paid license) editions when your application needs require more >> features and scalability. > > I'm weighing the pros and cons of SQL Server Compact Edition. Right now, > my main concern is that it requires an additional 1MB in my distributables > and that is a concern. Perhaps, I will try and find your eBook on it to > further clarify my thinking. Thanks for that. > >> I think you would benefit from reading my eBook on SQL Server Compact >> edition or my Hitchhiker's Guide. And yes, there are other books out >> there on data access application design but most are not written for >> those just getting started with .NET. Mine is. > > Yes, and I've purchased your book. But I've got other books ahead of it > and, when I'm done with those, I'll try and make a determination if your > book makes sense for me. Hopefully, by then, I'll have a better idea of > the direction I'm going in some of these fundamental issues. > > Jonathan >
You started this message thread, you have got more than one answer on the question you ask again and again, do you know what is the name for somebody who does this? However to do it again: SQL express is free for everybody, you can deploy it as many times as you want. Cor
Cor, [quoted text, click to view] > You started this message thread, you have got more than one answer on the > question you ask again and again, do you know what is the name for > somebody who does this?
I've received conflicting information in this thread and I think it is unfair to criticize me for asking the question again. Although William does not understand my customers as well as I do, he has demonstrated he understood the question. [quoted text, click to view] > SQL express is free for everybody, you can deploy it as many times as you > want.
The issue is one of deployment. SQL Server Express is out of the question for the reasons I have explained repeatedly in this thread. At any rate, while I find SQL Server Compact Edition intriguing, I'm concluding that I will writing my own data routines for the project in question. -- Jonathan Wood SoftCircuits Programming http://www.softcircuits.com
Don't see what you're looking for? Try a search.
|