|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Access vs SQLI've been developing a VB.NET app that requires the use of a DB. Up to now, I've been using Access. It's a bit slow, but everything works. I'm at a point now where I need to decide if I should stay with Access or move the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a move. My list is a bit lopsided, as I have very little experience with SQL and quite a bit with Access. PROS for moving to SQL: Increased Performance? Increased Reliability? Lifecycle of Access? Future Access Version compatibility issues? CONS for moving to SQL: My limited knowledge of SQL Clients not required to have an SQL server I've added a few items to the PROS list, but with ?s, as I don't really know. If there are a few Access advocates and SQL advocates out there that could give me some viewpoints, I'd be more comfortable making a decision based on the facts, rather than my limited knowledge. TIA Lee Hi,
The MSDE is a free scaled back version of sql server. So the client isn't required to buy sql server. If you design an app using msde and later need the networking features of sql server it is real easy to upgrade you app. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmsde/html/usingmsde.asp http://www.microsoft.com/downloads/details.aspx?FamilyID=6e9a7403-c4ba-4d98-bb0b-2c9d6414071f&DisplayLang=en Ken -------------------- "lgbjr" <lgbjr@online.nospam> wrote in message I've been developing a VB.NET app that requires the use of a DB. Up to now,news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... Hello All, I've been using Access. It's a bit slow, but everything works. I'm at a point now where I need to decide if I should stay with Access or move the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a move. My list is a bit lopsided, as I have very little experience with SQL and quite a bit with Access. PROS for moving to SQL: Increased Performance? Increased Reliability? Lifecycle of Access? Future Access Version compatibility issues? CONS for moving to SQL: My limited knowledge of SQL Clients not required to have an SQL server I've added a few items to the PROS list, but with ?s, as I don't really know. If there are a few Access advocates and SQL advocates out there that could give me some viewpoints, I'd be more comfortable making a decision based on the facts, rather than my limited knowledge. TIA Lee You've got a CON for SQL that "Clients not required to have an SQL server".
I'd say that's a PRO. Here are some other major issues to consider: Access has limited concurrent connection support while SQL Server was designed as a server, so it supports many concurrent connections. Access does not support Stored Procedures but SQL Server does. Access does not implement any db security (beyond a db password), but SQL Server has a robust security model. Show quoteHide quote "lgbjr" <lgbjr@online.nospam> wrote in message news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... > Hello All, > > I've been developing a VB.NET app that requires the use of a DB. Up to > now, I've been using Access. It's a bit slow, but everything works. I'm at > a point now where I need to decide if I should stay with Access or move > the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a > move. My list is a bit lopsided, as I have very little experience with SQL > and quite a bit with Access. > > PROS for moving to SQL: > Increased Performance? > Increased Reliability? > Lifecycle of Access? > Future Access Version compatibility issues? > > CONS for moving to SQL: > My limited knowledge of SQL > Clients not required to have an SQL server > > I've added a few items to the PROS list, but with ?s, as I don't really > know. > > If there are a few Access advocates and SQL advocates out there that could > give me some viewpoints, I'd be more comfortable making a decision based > on the facts, rather than my limited knowledge. > > TIA > Lee > > > Scott and Ken,
For staying with Access, you're right, that should be a PRO. Thanks for the tips. I guess I sort of knew these things, just from the reading I've done. And, I'm almost certain that the right long term decision is to move to SQL Server. I think I might take Ken's advice and take a baby step in what is probably the right direction by using MSDE to start. My basic concern is not my lack of SQL Server knowledge. I just felt that using SQL Server for what my app needs was a bit of overkill. And, thus, requiring my clients to purchase SQL Server seemed wrong. But, this thinking is based on what my app does today. So, no decision yet, but, I think MSDE gives me the easy scalability for the future, without the overkill of SQL Server today. Thanks! Lee Show quoteHide quote "Scott M." <s-mar@nospam.nospam> wrote in message news:eTQdo0PPFHA.3928@TK2MSFTNGP09.phx.gbl... > You've got a CON for SQL that "Clients not required to have an SQL > server". I'd say that's a PRO. > > Here are some other major issues to consider: > > Access has limited concurrent connection support while SQL Server was > designed as a server, so it supports many concurrent connections. > Access does not support Stored Procedures but SQL Server does. > Access does not implement any db security (beyond a db password), but SQL > Server has a robust security model. > > > "lgbjr" <lgbjr@online.nospam> wrote in message > news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... >> Hello All, >> >> I've been developing a VB.NET app that requires the use of a DB. Up to >> now, I've been using Access. It's a bit slow, but everything works. I'm >> at a point now where I need to decide if I should stay with Access or >> move the DB to SQL. I'm trying to come up with a list of Pros/Cons for >> such a move. My list is a bit lopsided, as I have very little experience >> with SQL and quite a bit with Access. >> >> PROS for moving to SQL: >> Increased Performance? >> Increased Reliability? >> Lifecycle of Access? >> Future Access Version compatibility issues? >> >> CONS for moving to SQL: >> My limited knowledge of SQL >> Clients not required to have an SQL server >> >> I've added a few items to the PROS list, but with ?s, as I don't really >> know. >> >> If there are a few Access advocates and SQL advocates out there that >> could give me some viewpoints, I'd be more comfortable making a decision >> based on the facts, rather than my limited knowledge. >> >> TIA >> Lee >> >> >> > > Hi Igbjr,
I am in exactly the same situation as you. My biggest concerns about SQL or any other server based DB are (1) the initial installation/setup issues and (2) the skill level required by my customers to maintain it. My customer base is the food industry and for the most part they do not have IT departments and DBA's in the packing plants to support "high technology". And it does not have to be very "high" to exceed their limits. I have used Access for many years and found it easy on both accounts. Since my databases are only accessed programatically and I do not use bound controls but open/close very quickly, I have never ran into concurrency issues. I have also not found problems with MDB file size yet but that is my major concern. In addition to MSDE as a starting point, I am also considering MySql and Firebird. So I will continue to lurk this thread and hope you get more insight form the Gurus. Also would appreciate hearing how you will make your decision to move away from Access. John Show quoteHide quote On Sat, 9 Apr 2005 20:29:05 +0800, "lgbjr" <lgbjr@online.nospam> wrote: >Scott and Ken, > >For staying with Access, you're right, that should be a PRO. > >Thanks for the tips. I guess I sort of knew these things, just from the >reading I've done. And, I'm almost certain that the right long term decision >is to move to SQL Server. I think I might take Ken's advice and take a baby >step in what is probably the right direction by using MSDE to start. > >My basic concern is not my lack of SQL Server knowledge. I just felt that >using SQL Server for what my app needs was a bit of overkill. And, thus, >requiring my clients to purchase SQL Server seemed wrong. But, this thinking >is based on what my app does today. > >So, no decision yet, but, I think MSDE gives me the easy scalability for the >future, without the overkill of SQL Server today. > >Thanks! > >Lee > > >"Scott M." <s-mar@nospam.nospam> wrote in message >news:eTQdo0PPFHA.3928@TK2MSFTNGP09.phx.gbl... >> You've got a CON for SQL that "Clients not required to have an SQL >> server". I'd say that's a PRO. >> >> Here are some other major issues to consider: >> >> Access has limited concurrent connection support while SQL Server was >> designed as a server, so it supports many concurrent connections. >> Access does not support Stored Procedures but SQL Server does. >> Access does not implement any db security (beyond a db password), but SQL >> Server has a robust security model. >> >> >> "lgbjr" <lgbjr@online.nospam> wrote in message >> news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... >>> Hello All, >>> >>> I've been developing a VB.NET app that requires the use of a DB. Up to >>> now, I've been using Access. It's a bit slow, but everything works. I'm >>> at a point now where I need to decide if I should stay with Access or >>> move the DB to SQL. I'm trying to come up with a list of Pros/Cons for >>> such a move. My list is a bit lopsided, as I have very little experience >>> with SQL and quite a bit with Access. >>> >>> PROS for moving to SQL: >>> Increased Performance? >>> Increased Reliability? >>> Lifecycle of Access? >>> Future Access Version compatibility issues? >>> >>> CONS for moving to SQL: >>> My limited knowledge of SQL >>> Clients not required to have an SQL server >>> >>> I've added a few items to the PROS list, but with ?s, as I don't really >>> know. >>> >>> If there are a few Access advocates and SQL advocates out there that >>> could give me some viewpoints, I'd be more comfortable making a decision >>> based on the facts, rather than my limited knowledge. >>> >>> TIA >>> Lee >>> >>> >>> >> >> > > My basic concern is not my lack of SQL Server knowledge. I just felt that You can administer MSDE through an Access front via *.adp Projects. There> using SQL Server for what my app needs was a bit of overkill. And, thus, > requiring my clients to purchase SQL Server seemed wrong. But, this thinking > is based on what my app does today. are also a bunch of free utilities out there to do this for you. Your right to base your decision on what your application does today not tomorrow..... thats why you undertake a requirements definition and vigilantly guard against *creeping scope*. .. From a coding standpoint the best thing you can do re: future proofing is too ensure you have proper separation of your data access layers. A change of DAL 18 months from now should not neccessitate a complete rewrite. In fact it could be considered a marketable feature/benefit if you design your DAL correctly using say the *Provider Pattern* that your application can run on the *customers* choice of data store - XML, my sql- whatever - this could be decided on a per client basis ( subject to your support preferences of course). I appreciate you're on a knowledge quest but if you really want future proofing Id start with application design, proper nTier development and pattern usage. If you do this correctly choice of datastore should almost be as easy as plug and play. Richard Scott,
> Access does not support Stored Procedures but SQL Server does. See in this procedurehttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k/html/acadvsql.asp Cor lgbjr,
Not that I am against any database however the major pro for me from access. And that only because that I have not seen it yet. Access is very easy to install and it is portable. Cor "lgbjr" <lgbjr@online.nospam> wrote in message <Snipped>news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... > Hello All, > > I've been developing a VB.NET app that requires the use of a DB. Up to now, > I've been using Access. It's a bit slow, but everything works. I'm at a > point now where I need to decide if I should stay with Access or move the DB > to SQL. I'm trying to come up with a list of Pros/Cons for such a move. My > list is a bit lopsided, as I have very little experience with SQL and quite > a bit with Access. > As you have found, sometimes there is no clear winner out of the gate. As others have mentioned, let's add the 3rd option of MSDE, so the basic choices we are considering are Access, MSDE, and SQL. Each of those options can be made to do just about anything you need, with increased options as you go up the list. So I propose that instead of basing your decisions on the merits of each DB engine, consider the needs of your application and customers. Then go down the list and see which one fits each item and score it. How many users will need to access the database simultaneously? Are you using the database primarily as a storage place, or do you have many updates? How much data are you storing? How processor intensive is your application? Do the customers need to use and/or manage the database outside of your application? Access: Best for single user. But can support many users if necessary. Pros: Works great as a storage container. Works best for smaller amounts of data, say dozens of MB. Although you can get close to 2GB. Fairly decent if your application is processor intensive. Works great in low memory environment. Easy to manage. Very portable and easy to install just about anywhere. Cons: If you have many updates then you need to constantly compact it. The 2GB limit can be reached fairly easily if you have lots of updates. Inefficient across a network. Version updates can be problematic. Best performance if you use DAO. Future upgrade to MSDE or SQL is not seemless and requires many code changes. Can use ADO for near seemless upgrade to MSDE or SQL, but performance is much less than DAO. MSDE: Best for 2-5 users. Can support more, but don't exceed 25. Pros: Handles many updates more efficiently than Access. Can store up to 2GB per database. No additional cost to your clients. Near seemless upgrade to full SQL. Usually few, if any, code changes needed. Cons: If your application is processor intensive, then you should set up a seperate server machine. If loaded on the same machine, then the processor requirements of your application could negate any performance gains. Requires more memory. If your database is small, can be less efficient than Access. Designed to be managed completely by your application. Not easy for clients to manage. Less portable than Access. SQL: Best for 6+ users. Pros: Handles queries and updates very efficiently. Can store up to 2GB+ (depending upon version, OS, etc) per database. Can be easily managed and accessed by your clients. Cons: Should really have a seperate machine, preferrably a server, dedicated to it. Requires a great deal of memory. Can require significant additional cost to your clients. Need Server OS and client licensese, SQL Server software, server license, plus client licenses. I wouldn't consider it portable at all. It is quite possible that moving up to MSDE might be a great choice. However, if you really don't need it, it is also quite likely that with tweaking you could significantly improve the performance of your Access code. Quite often, simple things like the choice of your Cursor location and recordset type can have large performance differences when using Access. Hope this helps. Gerald Hello All,
Thank You for your responses! All of you have given me quite a bit to think about! Richard, I understand completely. A bit of background: Even though I am developing a software package, I would not, by any stretch of the imagination, consider myself a software developer. I'm an Engineering Consultant for the Mobile Communications Industry. For the past 10 years, I've been writing PERL apps (when necessary) to automate repetitive tasks and make my life easier. These apps were for my use only. Over the years, I have had several clients ask me to provide these small apps to them. So, I moved from writing plain code, to writing an app with a user-friendly interface. Now, my clients want more. And they're willing to pay for it (above and beyond what they pay for my engineering services). Fortunately, I knew enough to write a scope of work (basically for myself), just as I would do for a typical engineering project. So, I do understand 'creeping scope'. Regarding the ability to 'Plug and Play' a variety of DB engines, I have considered this as well. At the beginning of this project, I was using C1 Express components (no data adapters, no datasets, just Express Tables and an Express connection (OLEDB)). While this was extremely easy to implement, I realized that there was no upgrade path (upgrade = rewrite). Now, still using C1 components, I know (think) I can upsize to MSDE or SQL Server with only minor code changes. Gerald, I agree. Rather than trying to decide which DB engine is better, it's safe to say that all are good, if used in the environment they were designed for. Right now, wihtout thinking about growth, I could deploy with Access (1-2 users performing updates, additional 3-4 users viewing data, approximately 1-1.5GB size). But, this, based on what I have read, and your comments, is near the upper limit of what Access was designed for. JL, though it may not seem so, I am in a similar situation regarding IT support. Even though all of the mobile operators have extensive IT departments, the engineering and IT departments are always fighting. So, I need my app to be self-maintainable. After posting this, I'm going to install SQL2KDesktop (MSDE) and try to get a feel for what it will take to do a migration (I already have SQL Server running on another machine). I like Richard's idea of allowing the client to decide which DB engine to use. Hopefully my coding and forward-thinking was robust enough to allow this with only some minor tweaks. However, if I get lost in a sea of errors, I think my backup will be to use MSDE. Again, thanks for your insights!! Regards, Lee Show quoteHide quote "lgbjr" <lgbjr@online.nospam> wrote in message news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... > Hello All, > > I've been developing a VB.NET app that requires the use of a DB. Up to > now, I've been using Access. It's a bit slow, but everything works. I'm at > a point now where I need to decide if I should stay with Access or move > the DB to SQL. I'm trying to come up with a list of Pros/Cons for such a > move. My list is a bit lopsided, as I have very little experience with SQL > and quite a bit with Access. > > PROS for moving to SQL: > Increased Performance? > Increased Reliability? > Lifecycle of Access? > Future Access Version compatibility issues? > > CONS for moving to SQL: > My limited knowledge of SQL > Clients not required to have an SQL server > > I've added a few items to the PROS list, but with ?s, as I don't really > know. > > If there are a few Access advocates and SQL advocates out there that could > give me some viewpoints, I'd be more comfortable making a decision based > on the facts, rather than my limited knowledge. > > TIA > Lee > > > > After posting this, I'm going to install SQL2KDesktop (MSDE) and try to You might want to check this out too Lee> get a feel for what it will take to do a migration (I already have SQL > Server running on another machine). I like Richard's idea of allowing the > client to decide which DB engine to use. Hopefully my coding and > forward-thinking was robust enough to allow this with only some minor > tweaks. However, if I get lost in a sea of errors, I think my backup will > be to use MSDE. http://www.asql.biz/DbaMgr.shtm It's a very nice (and free) admin GUI for MSDE. Very useful since MSDE comes with nothing Steve Hi All,
LOL! I've quite enjoyed reading all of the posts in this thread. To get back to the original topic for a second, I just wanted to let everyone know what I decided to do. I downloaded and installed MSDE 2000 (as well as DBAMgr2K). I did an upsize from Access, tweaked my app a bit, and viola, everything works. while downloading and installing MSDE 2000, my only thoughts were that Access was simple (I'm always on a quest to keep things simple for my users). MSDE 2000 adds a bit of complexity, but I have to say, compared to the performance gains, it's well worth it. Two of the tables have OLEObject (picture) fields (6 in one table, 8 in another). while running my app with the "Jet or Access or MS Access" DB (wink), there was a noticeable delay in retrieving and displaying records from the DB that had pictures. With MSDE, pictures, or no pictures, retrieving records is fast! thanks for all of the advice, and the entertainment!! Lee Show quoteHide quote "lgbjr" <lgbjr@online.nospam> wrote in message news:ORcBmJXPFHA.2680@TK2MSFTNGP09.phx.gbl... > Hello All, > > Thank You for your responses! All of you have given me quite a bit to > think about! > > Richard, I understand completely. A bit of background: Even though I am > developing a software package, I would not, by any stretch of the > imagination, consider myself a software developer. I'm an Engineering > Consultant for the Mobile Communications Industry. For the past 10 years, > I've been writing PERL apps (when necessary) to automate repetitive tasks > and make my life easier. These apps were for my use only. Over the years, > I have had several clients ask me to provide these small apps to them. So, > I moved from writing plain code, to writing an app with a user-friendly > interface. Now, my clients want more. And they're willing to pay for it > (above and beyond what they pay for my engineering services). Fortunately, > I knew enough to write a scope of work (basically for myself), just as I > would do for a typical engineering project. So, I do understand 'creeping > scope'. > > Regarding the ability to 'Plug and Play' a variety of DB engines, I have > considered this as well. At the beginning of this project, I was using C1 > Express components (no data adapters, no datasets, just Express Tables and > an Express connection (OLEDB)). While this was extremely easy to > implement, I realized that there was no upgrade path (upgrade = rewrite). > Now, still using C1 components, I know (think) I can upsize to MSDE or SQL > Server with only minor code changes. > > Gerald, I agree. Rather than trying to decide which DB engine is better, > it's safe to say that all are good, if used in the environment they were > designed for. Right now, wihtout thinking about growth, I could deploy > with Access (1-2 users performing updates, additional 3-4 users viewing > data, approximately 1-1.5GB size). But, this, based on what I have read, > and your comments, is near the upper limit of what Access was designed > for. > > JL, though it may not seem so, I am in a similar situation regarding IT > support. Even though all of the mobile operators have extensive IT > departments, the engineering and IT departments are always fighting. So, I > need my app to be self-maintainable. > > After posting this, I'm going to install SQL2KDesktop (MSDE) and try to > get a feel for what it will take to do a migration (I already have SQL > Server running on another machine). I like Richard's idea of allowing the > client to decide which DB engine to use. Hopefully my coding and > forward-thinking was robust enough to allow this with only some minor > tweaks. However, if I get lost in a sea of errors, I think my backup will > be to use MSDE. > > Again, thanks for your insights!! > > Regards, > Lee > > > > "lgbjr" <lgbjr@online.nospam> wrote in message > news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... >> Hello All, >> >> I've been developing a VB.NET app that requires the use of a DB. Up to >> now, I've been using Access. It's a bit slow, but everything works. I'm >> at a point now where I need to decide if I should stay with Access or >> move the DB to SQL. I'm trying to come up with a list of Pros/Cons for >> such a move. My list is a bit lopsided, as I have very little experience >> with SQL and quite a bit with Access. >> >> PROS for moving to SQL: >> Increased Performance? >> Increased Reliability? >> Lifecycle of Access? >> Future Access Version compatibility issues? >> >> CONS for moving to SQL: >> My limited knowledge of SQL >> Clients not required to have an SQL server >> >> I've added a few items to the PROS list, but with ?s, as I don't really >> know. >> >> If there are a few Access advocates and SQL advocates out there that >> could give me some viewpoints, I'd be more comfortable making a decision >> based on the facts, rather than my limited knowledge. >> >> TIA >> Lee >> >> >> > > You are on the right path Lee. Good luck!
Show quoteHide quote "lgbjr" <lgbjr@online.nospam> wrote in message news:uB6s%23HDQFHA.604@TK2MSFTNGP10.phx.gbl... > Hi All, > > LOL! I've quite enjoyed reading all of the posts in this thread. To get > back to the original topic for a second, I just wanted to let everyone > know what I decided to do. > > I downloaded and installed MSDE 2000 (as well as DBAMgr2K). I did an > upsize from Access, tweaked my app a bit, and viola, everything works. > > while downloading and installing MSDE 2000, my only thoughts were that > Access was simple (I'm always on a quest to keep things simple for my > users). MSDE 2000 adds a bit of complexity, but I have to say, compared to > the performance gains, it's well worth it. Two of the tables have > OLEObject (picture) fields (6 in one table, 8 in another). while running > my app with the "Jet or Access or MS Access" DB (wink), there was a > noticeable delay in retrieving and displaying records from the DB that had > pictures. With MSDE, pictures, or no pictures, retrieving records is fast! > > thanks for all of the advice, and the entertainment!! > > Lee > > "lgbjr" <lgbjr@online.nospam> wrote in message > news:ORcBmJXPFHA.2680@TK2MSFTNGP09.phx.gbl... >> Hello All, >> >> Thank You for your responses! All of you have given me quite a bit to >> think about! >> >> Richard, I understand completely. A bit of background: Even though I am >> developing a software package, I would not, by any stretch of the >> imagination, consider myself a software developer. I'm an Engineering >> Consultant for the Mobile Communications Industry. For the past 10 years, >> I've been writing PERL apps (when necessary) to automate repetitive tasks >> and make my life easier. These apps were for my use only. Over the years, >> I have had several clients ask me to provide these small apps to them. >> So, I moved from writing plain code, to writing an app with a >> user-friendly interface. Now, my clients want more. And they're willing >> to pay for it (above and beyond what they pay for my engineering >> services). Fortunately, I knew enough to write a scope of work (basically >> for myself), just as I would do for a typical engineering project. So, I >> do understand 'creeping scope'. >> >> Regarding the ability to 'Plug and Play' a variety of DB engines, I have >> considered this as well. At the beginning of this project, I was using C1 >> Express components (no data adapters, no datasets, just Express Tables >> and an Express connection (OLEDB)). While this was extremely easy to >> implement, I realized that there was no upgrade path (upgrade = rewrite). >> Now, still using C1 components, I know (think) I can upsize to MSDE or >> SQL Server with only minor code changes. >> >> Gerald, I agree. Rather than trying to decide which DB engine is better, >> it's safe to say that all are good, if used in the environment they were >> designed for. Right now, wihtout thinking about growth, I could deploy >> with Access (1-2 users performing updates, additional 3-4 users viewing >> data, approximately 1-1.5GB size). But, this, based on what I have read, >> and your comments, is near the upper limit of what Access was designed >> for. >> >> JL, though it may not seem so, I am in a similar situation regarding IT >> support. Even though all of the mobile operators have extensive IT >> departments, the engineering and IT departments are always fighting. So, >> I need my app to be self-maintainable. >> >> After posting this, I'm going to install SQL2KDesktop (MSDE) and try to >> get a feel for what it will take to do a migration (I already have SQL >> Server running on another machine). I like Richard's idea of allowing the >> client to decide which DB engine to use. Hopefully my coding and >> forward-thinking was robust enough to allow this with only some minor >> tweaks. However, if I get lost in a sea of errors, I think my backup will >> be to use MSDE. >> >> Again, thanks for your insights!! >> >> Regards, >> Lee >> >> >> >> "lgbjr" <lgbjr@online.nospam> wrote in message >> news:exGmoIPPFHA.2144@TK2MSFTNGP09.phx.gbl... >>> Hello All, >>> >>> I've been developing a VB.NET app that requires the use of a DB. Up to >>> now, I've been using Access. It's a bit slow, but everything works. I'm >>> at a point now where I need to decide if I should stay with Access or >>> move the DB to SQL. I'm trying to come up with a list of Pros/Cons for >>> such a move. My list is a bit lopsided, as I have very little experience >>> with SQL and quite a bit with Access. >>> >>> PROS for moving to SQL: >>> Increased Performance? >>> Increased Reliability? >>> Lifecycle of Access? >>> Future Access Version compatibility issues? >>> >>> CONS for moving to SQL: >>> My limited knowledge of SQL >>> Clients not required to have an SQL server >>> >>> I've added a few items to the PROS list, but with ?s, as I don't really >>> know. >>> >>> If there are a few Access advocates and SQL advocates out there that >>> could give me some viewpoints, I'd be more comfortable making a decision >>> based on the facts, rather than my limited knowledge. >>> >>> TIA >>> Lee >>> >>> >>> >> >> > > Haven't read all the replies, so apologies if this has aready been
said: 1. Access is *not* a database. It is a front-end IDE. The underlying database for Access is normally MS Jet, a comlementary but completely seperate product. You can have an Access front-end with any compatible database including but not limited to Jet, Oracle, SQL Server, etc. Conversely, you can use a Jet database with any complementary front-end including but not limited to Access, VB, etc. 2. SQL also is *not* a database. SQL is a data access language which is used in many databases, including but not limited to Jet, SQL Server, Oracle, etc. IOW, please let's get the terminolgy right :-) HTH, TC > In my opinion is this sentence wrong.> 1. Access is *not* a database. It is not a database *server* however it is a database system in a file. I hope this helps, Cor Not so, Cor.
MS Access does not contain any of the base technologies for creating & managing tables & indexes; parsing, optimizing & executing SQL; or any of the other things that database products have to do. Those technologies all reside in a completely seperate product, MS Jet. Access uses the Jet API to create & maintain tables & indexes, execute SQL, and so on. Access does ask Jet (via a Jet API) to create, within the MDB file, some containers for Access to store its own things (forms, reports etc.) - but that does not make Access, a database. I suspect your mistake is in believing that an MDB file is an *Access* file. It is not - it is a *Jet* file, in which Access is able to store its own things (in addition to the standard Jet things). A VB program can use a Jet MDB file for database storage; but VB is not Access, and does not require Access to be present in any way, shape or form. HTH TC TC,
You make in my opinion a mistake what is a database. For a database is not even SQL required (In the last case we are mostly talking about a relational database). It only needs that the data is accessable in a random way and that there is an ability to replace parts of the data when there is an update, delete or insert. Cor You miss my point as to which components perform what tasks.
I don't intend to comment further. Cheers, TC TC,
Sorry, your points sounds for me as splitting hairs. Which sounds for me the same as if you want to tell that somebody born in the US is not an American but an USan and somebody born in the EU is not an European but an EUan. Everybody visiting this newsgroups knows what is meant (and use that in relation) by the Access database and are in the same way telling about MS Access that it is an application. Just my thought, Cor On 10 Apr 2005 18:58:31 -0700, aatcbbtcc***@yahoo.com wrote:
¤ Not so, Cor. ¤ ¤ MS Access does not contain any of the base technologies for creating & ¤ managing tables & indexes; parsing, optimizing & executing SQL; or any ¤ of the other things that database products have to do. ¤ ¤ Those technologies all reside in a completely seperate product, MS Jet. ¤ Access uses the Jet API to create & maintain tables & indexes, execute ¤ SQL, and so on. ¤ This is incorrect. I'm not sure why you're attempting to separate Jet from Microsoft Access. Each version of Microsoft Access is actually hard-wired for a specific version of Jet and the functionality is essentially integrated. You can also use DAO, ADO etc (independently) to work with an Access database directly or via OLEDB or ODBC drivers but there isn't the same level of support as when using the Microsoft Access application. ¤ Access does ask Jet (via a Jet API) to create, within the MDB file, ¤ some containers for Access to store its own things (forms, reports ¤ etc.) - but that does not make Access, a database. ¤ Huh? ¤ I suspect your mistake is in believing that an MDB file is an *Access* ¤ file. It is not - it is a *Jet* file, in which Access is able to store ¤ its own things (in addition to the standard Jet things). ¤ Baloney. It can contain data, code and database related objects that are native to the Microsoft Access application. An MDB file *is* an Access database. ¤ A VB program can use a Jet MDB file for database storage; but VB is not ¤ Access, and does not require Access to be present in any way, shape or ¤ form. That is, unless you attempt to use functionality that is not supported by Jet, but is only available through the Microsoft Access application. Paul ~~~~ Microsoft MVP (Visual Basic) How about if we say that an .mdb file is an Access file that wraps a JET
database and adds extensions of its own? "Can't we all just get along?" I think the fundamental point here is that there is no such thing as DATA stored in Access format. An Access file is DATA stored in a JET database along with Access elements such as reports, forms, VBA code, etc. and all of that is placed in an Access .mdb file. The proof in the pudding is that the data stored in an Access file can be programmatically accessed and manipulated without having the Access client because the actual data is not stored in an Access format, but in a JET database. Show quoteHide quote "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message news:t1il51du905tem6agf6esaea8mj06300d9@4ax.com... > On 10 Apr 2005 18:58:31 -0700, aatcbbtcc***@yahoo.com wrote: > > ¤ Not so, Cor. > ¤ > ¤ MS Access does not contain any of the base technologies for creating & > ¤ managing tables & indexes; parsing, optimizing & executing SQL; or any > ¤ of the other things that database products have to do. > ¤ > ¤ Those technologies all reside in a completely seperate product, MS Jet. > ¤ Access uses the Jet API to create & maintain tables & indexes, execute > ¤ SQL, and so on. > ¤ > > This is incorrect. > > I'm not sure why you're attempting to separate Jet from Microsoft Access. > Each version of Microsoft > Access is actually hard-wired for a specific version of Jet and the > functionality is essentially > integrated. You can also use DAO, ADO etc (independently) to work with an > Access database directly > or via OLEDB or ODBC drivers but there isn't the same level of support as > when using the Microsoft > Access application. > > ¤ Access does ask Jet (via a Jet API) to create, within the MDB file, > ¤ some containers for Access to store its own things (forms, reports > ¤ etc.) - but that does not make Access, a database. > ¤ > > Huh? > > ¤ I suspect your mistake is in believing that an MDB file is an *Access* > ¤ file. It is not - it is a *Jet* file, in which Access is able to store > ¤ its own things (in addition to the standard Jet things). > ¤ > > Baloney. It can contain data, code and database related objects that are > native to the Microsoft > Access application. An MDB file *is* an Access database. > > ¤ A VB program can use a Jet MDB file for database storage; but VB is not > ¤ Access, and does not require Access to be present in any way, shape or > ¤ form. > > That is, unless you attempt to use functionality that is not supported by > Jet, but is only available > through the Microsoft Access application. > > > Paul > ~~~~ > Microsoft MVP (Visual Basic) Scott,
> And what does that mean in your opinion about any other database. In this > I think the fundamental point here is that there is no such thing as DATA > stored in Access format. An Access file is DATA stored in a JET database > along with Access elements such as reports, forms, VBA code, etc. and all > of that is placed in an Access .mdb file. > thread is by one person denied that an Access datatase is a database. He tells that it is a kind of application that uses a Jet database. What is not false, however is in my opinion with an Access database normaly used the same database and when we talk about the application we talk about MS Access (at least I do). Cor > And what does that mean in your opinion about any other database. We're not talking about other databases in this thread. Access is special in this regard. > In this thread is by one person denied that an Access datatase is a Actually, I think pretty much everyone in this thread (except you) has said > database. He tells that it is a kind of application that uses a Jet > database. this...because it's true. >What is not false, however is in my opinion with an Access database normaly It's true that for most discussions, people will tend to say "Access" when >used the same database and when we talk about the application we talk about >MS Access (at least I do). talking about the MS Access software product as well as when they are referring to the "type" of database they are using. For *most* conversations that is fine because most people will know what you mean. For the purpose of this thread though, we must get a bit more technical and separate the database from the product that uses that database. Technically speaking, there is no such database storage format as "Access", there is the JET database storage format that Access uses and wraps. Think about this for a second Cor...if I wanted to connect to the data stored in a MS Access file (.mdb), I'd have several choices: DAO - DAO is a data access paradigm that ONLY works with JET databases ADO - ADO would need a connection object and the connection object would need a connection string. The connection string would be this: Proider=Microsoft.JET.4.0;Data Source=.... (notice the JET in there?) ADO.NET - same as ADO Scott,
>> And what does that mean in your opinion about any other database. Before you write next time something, look than at least at the topic.> > We're not talking about other databases in this thread. Access is special > in this regard. > > Actually, I think pretty much everyone in this thread (except you) has Read the messages, I have not the idea beside you and the one who told that > said this...because it's true. > Microsoft don't know what Access is wrote the same as you. Look for the rest too the answer from Paul. Cor >>> And what does that mean in your opinion about any other database. -----> Before you write next time something, look than at least at the >> >> We're not talking about other databases in this thread. Access is >> special in this regard. >> topic. Cor, the last several times you have replied to my comments in other threads, you have come back at me with cryptic responses like this one. What are you trying to say? I have read this thread and my posts are very clear on what I'm saying. Your posts, on the other hand, are contradictory and confusing. > Actually, I think pretty much everyone in this thread (except you) has -----> Read the messages, I have not the idea beside you and the one who >> said this...because it's true. >> > told that -----> Microsoft don't know what Access is wrote the same as you. I have absolutley no idea what you are trying to say here. > Look for the rest too the answer from Paul. Paul has posted 1 message in this thread prior to my comment to you and I disagree with him as well.
Show quote
Hide quote
"Scott M." <s-mar@nospam.nospam> schreef in bericht We are talking about the use of Access vs SQL (server) in this thread, look news:O81DVP4PFHA.548@TK2MSFTNGP10.phx.gbl... >>>> And what does that mean in your opinion about any other database. >>> >>> We're not talking about other databases in this thread. Access is >>> special in this regard. >>> > > -----> Before you write next time something, look than at least at the > topic. > > Cor, the last several times you have replied to my comments in other > threads, you have come back at me with cryptic responses like this one. > What are you trying to say? I have read this thread and my posts are very > clear on what I'm saying. Your posts, on the other hand, are > contradictory and confusing. > at the subject of all the messages. For me did you not notice that, because that is what you wrote. It does really not give me much believe that you did read this message thread. Cor LOL!!!
Cor, the subject may be Access vs. SQL, but the topic quickly turned to JET and Access. The fact that you want to ignore what we have actually been talking about here (including your own comments), just tells me that you have nothing else to offer. Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:eG3MPq4PFHA.3704@TK2MSFTNGP12.phx.gbl... > > "Scott M." <s-mar@nospam.nospam> schreef in bericht > news:O81DVP4PFHA.548@TK2MSFTNGP10.phx.gbl... >>>>> And what does that mean in your opinion about any other database. >>>> >>>> We're not talking about other databases in this thread. Access is >>>> special in this regard. >>>> >> >> -----> Before you write next time something, look than at least at the >> topic. >> >> Cor, the last several times you have replied to my comments in other >> threads, you have come back at me with cryptic responses like this one. >> What are you trying to say? I have read this thread and my posts are >> very clear on what I'm saying. Your posts, on the other hand, are >> contradictory and confusing. >> > We are talking about the use of Access vs SQL (server) in this thread, > look at the subject of all the messages. > > For me did you not notice that, because that is what you wrote. It does > really not give me much believe that you did read this message thread. > > Cor > Scott,
> Cor, the subject may be Access vs. SQL, but the topic quickly turned to We ????> JET and Access. The fact that you want to ignore what we have actually > been talking about here (including your own comments), just tells me that > you have nothing else to offer. > There was only one person beside later you, who in this thread told that access was not a db. This is from your first message in this thread. >Access does not implement any db security (beyond a db password) And now Access is no more a db, why has it than a db password.Scott, whatever you write in newsgroups can be checked, so watch what you write. However in the last sentence from your last message you are right, I have nothing more to offer in this thread, everything is already written in this thread and that was already before you started beating that dead horse. Cor It's clear Cor that English isn't your first language (not trying to insult
you, just stating a fact). And, it's clear that you haven't been reading or writing your English very well also. Let's go back and "check" the thread as you suggest: There were seven (7) messages on the "Access is or isn't a database" topic involving three (3) other people BESIDES myself BEFORE I said anything about Access and JET. Yes, I did say "Access does not implement any db security (beyond a db password)", but that doesn't automatically mean that Access is a database at all. It simply means that Access implements a password on the JET database. Are you really telling me that you couldn't put that together yourself? You confuse me to no end Cor, because you write such off the wall things. You constantly contradict yourself and state things that were never said by anyone as if they were said by me and then deny things that were said by yourself. You are really telling me that you don't understand the concept of a thread that breaks off into a sub-thread about a different twist on the original post? Seriously? And are you seriously telling me that you can't separate something that was said in one thread (when the term Access is used to refer to BOTH the product and the data as I stated in my earlier post that I guess you didn't read) from something that was said in a sub-thread (when we were discussing this on a more technical level where Access is NOT used to describe BOTH the product and the data)? If my posts confuse you, my desire to have you clarify yourself bothers you and my asking that you not go on babbling about un-related and non-factual information bothers you so, please feel free to filter me from your NG reader. You are constantly telling me to go back and read the thread, but it is you who isn't reading (or understanding) what is being said and is coming up with non-sensical statements. It's very clear what I am saying, to whom I said it and when, here's the summary: Access is not as good as SQL for concurrent users. Access does not support Stored Procedures to the extent that SQL does. Access does not support the same level of security that SQL does. Access is a product that wraps a JET database and extends it's UI via VBA, Forms, Queries and Reports. This is pretty darn clear Cor and it is almost identical to what I've said in the previous posts. You may not agree (and I respect your right to do so), but you seem to be the only one who doesn't, at least, understand what I'm saying. Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:%23uSx4C5PFHA.1500@TK2MSFTNGP09.phx.gbl... > Scott, > >> Cor, the subject may be Access vs. SQL, but the topic quickly turned to >> JET and Access. The fact that you want to ignore what we have actually >> been talking about here (including your own comments), just tells me that >> you have nothing else to offer. >> > > We ???? > > There was only one person beside later you, who in this thread told that > access was not a db. > > This is from your first message in this thread. >>Access does not implement any db security (beyond a db password) > > And now Access is no more a db, why has it than a db password. > > Scott, whatever you write in newsgroups can be checked, so watch what you > write. > > However in the last sentence from your last message you are right, I have > nothing more to offer in this thread, everything is already written in > this thread and that was already before you started beating that dead > horse. > > Cor > > By the way, did you even bother to READ this:
From: http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/jetintro.mspx "Since its introduction in 1992, the Microsoft Jet database engine has been in a unique position. Because Microsoft Jet is not a stand-alone product - you cannot buy it at your local software retailer - most developers who use it have learned about its functionality in a second-hand fashion from the documentation included in Microsoft Access, Microsoft Office, Microsoft Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. " Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:%23uSx4C5PFHA.1500@TK2MSFTNGP09.phx.gbl... > Scott, > >> Cor, the subject may be Access vs. SQL, but the topic quickly turned to >> JET and Access. The fact that you want to ignore what we have actually >> been talking about here (including your own comments), just tells me that >> you have nothing else to offer. >> > > We ???? > > There was only one person beside later you, who in this thread told that > access was not a db. > > This is from your first message in this thread. >>Access does not implement any db security (beyond a db password) > > And now Access is no more a db, why has it than a db password. > > Scott, whatever you write in newsgroups can be checked, so watch what you > write. > > However in the last sentence from your last message you are right, I have > nothing more to offer in this thread, everything is already written in > this thread and that was already before you started beating that dead > horse. > > Cor > > Here's even more from that same article:
"Microsoft Access Users When you create an object through DAO by using Microsoft Jet, only the standard built-in properties are created in the new object's Properties collection. However, when Microsoft Access creates a Microsoft Jet object, it may add several user-defined properties to objects. These properties are a special case of user-defined properties known as application-defined properties. For example, when you create a table in the Microsoft Access user interface, and type a value in the Description field, it automatically adds a new property to the TableDef object to represent the description." Notice how they refer to Access, not as the database, but as the "Microsoft Access user interface"? Notice how they talk about MS Access creating a "Microsoft Jet object"? And, if you read the whole article, you'll see them talk about the actual database being one of the DAO objects and that the DAO objects are APIs to JET objects. Is this clear enough for you? Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:%23uSx4C5PFHA.1500@TK2MSFTNGP09.phx.gbl... > Scott, > >> Cor, the subject may be Access vs. SQL, but the topic quickly turned to >> JET and Access. The fact that you want to ignore what we have actually >> been talking about here (including your own comments), just tells me that >> you have nothing else to offer. >> > > We ???? > > There was only one person beside later you, who in this thread told that > access was not a db. > > This is from your first message in this thread. >>Access does not implement any db security (beyond a db password) > > And now Access is no more a db, why has it than a db password. > > Scott, whatever you write in newsgroups can be checked, so watch what you > write. > > However in the last sentence from your last message you are right, I have > nothing more to offer in this thread, everything is already written in > this thread and that was already before you started beating that dead > horse. > > Cor > > From:
http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/jetintro.mspx "Since its introduction in 1992, the Microsoft Jet database engine has been in a unique position. Because Microsoft Jet is not a stand-alone product - you cannot buy it at your local software retailer - most developers who use it have learned about its functionality in a second-hand fashion from the documentation included in Microsoft Access, Microsoft Office, Microsoft Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. " Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:uJ3QV93PFHA.1396@TK2MSFTNGP10.phx.gbl... > Scott, > >>> And what does that mean in your opinion about any other database. >> >> We're not talking about other databases in this thread. Access is >> special in this regard. >> > Before you write next time something, look than at least at the topic. > >> Actually, I think pretty much everyone in this thread (except you) has >> said this...because it's true. >> > > Read the messages, I have not the idea beside you and the one who told > that Microsoft don't know what Access is wrote the same as you. > > Look for the rest too the answer from Paul. > > Cor > > On Mon, 11 Apr 2005 16:03:13 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ How about if we say that an .mdb file is an Access file that wraps a JET ¤ database and adds extensions of its own? ¤ ¤ "Can't we all just get along?" ¤ What's the fun in that? ;-) ¤ I think the fundamental point here is that there is no such thing as DATA ¤ stored in Access format. An Access file is DATA stored in a JET database ¤ along with Access elements such as reports, forms, VBA code, etc. and all of ¤ that is placed in an Access .mdb file. ¤ ¤ The proof in the pudding is that the data stored in an Access file can be ¤ programmatically accessed and manipulated without having the Access client ¤ because the actual data is not stored in an Access format, but in a JET ¤ database. So can an Excel Workbook. So can a CSV file. Does that make them "Jet databases"? Jet is the database access layer component for Microsoft Access. It does not define any specific type of database. It is not a product and many who use Access have absolutely no awareness of Jet. Paul ~~~~ Microsoft MVP (Visual Basic) Paul,
> Thanks for pointing us on that.> So can an Excel Workbook. So can a CSV file. Does that make them "Jet > databases"? > Cor > Jet is the database access layer component for Microsoft Access. It does It's true that most who use Access don't know anything about JET. That only > not define any specific > type of database. It is not a product and many who use Access have > absolutely no awareness of Jet. proves that Access wraps the JET database. Tell me, what is the connection string in ADO or ADO.NET to connect to an ..mdb file? Tell me, what is the only kind of data that DAO can connect to? On Tue, 12 Apr 2005 13:12:30 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ > Jet is the database access layer component for Microsoft Access. It does ¤ > not define any specific ¤ > type of database. It is not a product and many who use Access have ¤ > absolutely no awareness of Jet. ¤ ¤ It's true that most who use Access don't know anything about JET. That only ¤ proves that Access wraps the JET database. ¤ ¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an ¤ .mdb file? oConn.Open "Driver={Microsoft Access Driver (*.mdb)};" & _ "Dbq=c:\somepath\mydb.mdb;" & _ "Uid=admin;" & _ "Pwd=" ¤ Tell me, what is the only kind of data that DAO can connect to? ¤ DAO can connect to any number of database types including Microsoft Access and ODBC supported databases such as SQL Server and Oracle and ISAM databases such as xBase, Excel, Paradox etc. Paul ~~~~ Microsoft MVP (Visual Basic) ¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an
¤ .mdb file? > What you've shown here is what driver to use. Drivers are yet another way > oConn.Open "Driver={Microsoft Access Driver (*.mdb)};" & _ > "Dbq=c:\somepath\mydb.mdb;" & _ > "Uid=admin;" & _ > "Pwd=" to "wrap" the actual functionality of connecting to the data source. You are supplying a "satisfactory" connection string, while the actual DB provider is "Microsoft.OLEDB.JET.n.x" as seen in the more commonly used: Con.Open "Provider=Microsoft.JET.OLEDB.4.0.;Data Source=path" > Actually it's true, I mis-spoke, DAO does support more than just Access, > ¤ Tell me, what is the only kind of data that DAO can connect to? > ¤ > > DAO can connect to any number of database types including Microsoft Access > and ODBC supported > databases such as SQL Server and Oracle and ISAM databases such as xBase, > Excel, Paradox etc. however if you read the article I posted the link to, you will see this: "You can use the ODBCDirect object hierarchy to work with ODBC data sources without going through the Jet database engine." So, when you use ODBC, you are not connecting to a JET database. But, when you do use JET in DAO, you are now limited to JET databases (not SQL, Oracle, etc.). It's also interesting that in VB 6.0, if you make a Data Project and get into the connection's properties and look at the OLEDB providers, you don't see one for Access. What you do see is JET. And, if you select JET and then move on to select the corresponding database, it is even more interesting that the dialong box used to browse for these databases has only one file type that it is filtering on - - .mdb. The minutia of this thread has all but worn me out Paul. Read the article I posted and you will see that your argument holds up on a very high level, but not at the lower levels. There's nothing more I can say. On Wed, 13 Apr 2005 23:44:44 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ ¤ Tell me, what is the connection string in ADO or ADO.NET to connect to an¤ ¤ .mdb file? ¤ > ¤ > oConn.Open "Driver={Microsoft Access Driver (*.mdb)};" & _ ¤ > "Dbq=c:\somepath\mydb.mdb;" & _ ¤ > "Uid=admin;" & _ ¤ > "Pwd=" ¤ ¤ What you've shown here is what driver to use. Drivers are yet another way ¤ to "wrap" the actual functionality of connecting to the data source. You ¤ are supplying a "satisfactory" connection string, while the actual DB ¤ provider is "Microsoft.OLEDB.JET.n.x" as seen in the more commonly used: ¤ ¤ Con.Open "Provider=Microsoft.JET.OLEDB.4.0.;Data Source=path" ¤ Yes, but there isn't much point to this. The only reason that I posted that connection string, which I don't recommend using, is to point out that both Access and Jet can be used interchangeably. There is no right or wrong. But the key point is that the Jet Database Engine is a subset of the Microsoft Access application and that it does not have full control over all objects and data stored in a Microsoft Access database. Only the Access application has this capability whether it's via the Jet Database Engine or directly through the Access application code. Paul ~~~~ Microsoft MVP (Visual Basic) > Yes, but there isn't much point to this. The only reason that I posted I agree that there is no right or wrong (although I too don't recommend the > that > connection string, which I don't recommend using, is to point out that > both > Access and Jet can be used interchangeably. There is no right or wrong. the Access driver version). I also don't disagree that in *many* cases what we are discussing is minutia and makes little difference. But, when you start peeling back the layers of the Access product, you must begin to separate the Access software product from the actual data store. > But the key point is that the Jet Database Engine is a subset of the Again, what you say is not in dispute, but needs further clarification. The > Microsoft > Access application and that it does not have full control over all objects > and > data stored in a Microsoft Access database. Only the Access application > has this > capability whether it's via the Jet Database Engine or directly through > the > Access application code. Access product does store additional information that JET does not (reports, queries, forms, etc.) and an .mdb file is a file that holds the cumulative data (the JET database as well as the proprietary Access information). However, the main point I'm trying to drive home here is that the DATA itself (not the forms, reports, queries, etc. that compliment the data) is stored in a JET Database that MS Access simply wraps and extends. The result is placed into an .mdb file. In this context, JET and Access are not the same thing. On Thu, 14 Apr 2005 13:10:57 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ > But the key point is that the Jet Database Engine is a subset of the ¤ > Microsoft ¤ > Access application and that it does not have full control over all objects ¤ > and ¤ > data stored in a Microsoft Access database. Only the Access application ¤ > has this ¤ > capability whether it's via the Jet Database Engine or directly through ¤ > the ¤ > Access application code. ¤ ¤ Again, what you say is not in dispute, but needs further clarification. The ¤ Access product does store additional information that JET does not (reports, ¤ queries, forms, etc.) and an .mdb file is a file that holds the cumulative ¤ data (the JET database as well as the proprietary Access information). ¤ However, the main point I'm trying to drive home here is that the DATA ¤ itself (not the forms, reports, queries, etc. that compliment the data) is ¤ stored in a JET Database that MS Access simply wraps and extends. The ¤ result is placed into an .mdb file. In this context, JET and Access are not ¤ the same thing. ¤ Nobody said they were. All that was stated is that the terms Jet and Access may both be used to describe an Access database. But at the risk of repeating myself, the Access application is the only one of the two that has full control over an .mdb file. The Jet Database Engine was created for Microsoft Access and extended so that other development platforms could use it. The next thing you know, well be arguing over whether to call Word and Excel documents "OLE Structured Storage" files - because that is the underlying technology used. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) From:
http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/jetintro.mspx "Since its introduction in 1992, the Microsoft Jet database engine has been in a unique position. Because Microsoft Jet is not a stand-alone product - you cannot buy it at your local software retailer - most developers who use it have learned about its functionality in a second-hand fashion from the documentation included in Microsoft Access, Microsoft Office, Microsoft Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. " Show quoteHide quote "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message news:2mon511v6nd31e4u7tisc2d2m0n01k4fq5@4ax.com... > On Mon, 11 Apr 2005 16:03:13 -0400, "Scott M." <s-mar@nospam.nospam> > wrote: > > ¤ How about if we say that an .mdb file is an Access file that wraps a JET > ¤ database and adds extensions of its own? > ¤ > ¤ "Can't we all just get along?" > ¤ > > What's the fun in that? ;-) > > ¤ I think the fundamental point here is that there is no such thing as > DATA > ¤ stored in Access format. An Access file is DATA stored in a JET > database > ¤ along with Access elements such as reports, forms, VBA code, etc. and > all of > ¤ that is placed in an Access .mdb file. > ¤ > ¤ The proof in the pudding is that the data stored in an Access file can > be > ¤ programmatically accessed and manipulated without having the Access > client > ¤ because the actual data is not stored in an Access format, but in a JET > ¤ database. > > So can an Excel Workbook. So can a CSV file. Does that make them "Jet > databases"? > > Jet is the database access layer component for Microsoft Access. It does > not define any specific > type of database. It is not a product and many who use Access have > absolutely no awareness of Jet. > > > Paul > ~~~~ > Microsoft MVP (Visual Basic) On Tue, 12 Apr 2005 13:19:48 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ From:¤ ¤ http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/jetintro.mspx ¤ ¤ "Since its introduction in 1992, the Microsoft Jet database engine has been ¤ in a unique position. Because Microsoft Jet is not a stand-alone product - ¤ you cannot buy it at your local software retailer - most developers who use ¤ it have learned about its functionality in a second-hand fashion from the ¤ documentation included in Microsoft Access, Microsoft Office, Microsoft ¤ Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. " ¤ Isn't that kind of what I said? Do we now want to count the number of times the phrase "Jet database" and "Access database" are used interchangeably? Not much point is there. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) Uh, no it's not what you said at all. And, most importantly, if you read
this documentation you will see that the terms MS Access and JET are NOT used interchangeably. In fact, throughout the article, Access is referred to as the "Microsoft Access user interface". Show quoteHide quote "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message news:retq51p1e9mc3d3irv733kt7dgf58rjavt@4ax.com... > On Tue, 12 Apr 2005 13:19:48 -0400, "Scott M." <s-mar@nospam.nospam> > wrote: > > ¤ From: > ¤ > ¤ > http://www.microsoft.com/resources/documentation/sql/7/all/proddocs/en-us/msjet/jetintro.mspx > ¤ > ¤ "Since its introduction in 1992, the Microsoft Jet database engine has > been > ¤ in a unique position. Because Microsoft Jet is not a stand-alone > product - > ¤ you cannot buy it at your local software retailer - most developers who > use > ¤ it have learned about its functionality in a second-hand fashion from > the > ¤ documentation included in Microsoft Access, Microsoft Office, Microsoft > ¤ Visual Basic®, Microsoft Visual C++®, or Microsoft Visual J++®. " > ¤ > > Isn't that kind of what I said? > > Do we now want to count the number of times the phrase "Jet database" and > "Access database" are used > interchangeably? Not much point is there. ;-) > > > Paul > ~~~~ > Microsoft MVP (Visual Basic) On Wed, 13 Apr 2005 23:26:23 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ Uh, no it's not what you said at all. And, most importantly, if you read ¤ this documentation you will see that the terms MS Access and JET are NOT ¤ used interchangeably. In fact, throughout the article, Access is referred ¤ to as the "Microsoft Access user interface". ¤ Yes, but in other articles and documentation it is not. http://tinyurl.com/6acob Paul ~~~~ Microsoft MVP (Visual Basic) That's because the "other" articles you refer to aren't discussing the
low-level architecture of what is actually storing the data in Access. As I've said, in many situations the term "Access Database" is just fine to convey the meaning of what you are trying to say. What we are discussing is completely different than those high level discussions (such as the ones returned by your search). Just because I use 2 words interchangeable doesn't mean that they are the same thing technically. For example, in the OO world, the terms "object" and "class" are often interchanged and for many discussions that's fine. But there is a world of difference between what an "object" actually is vs. what a "class" actually is. The article I've provided is specifically about the low-level understanding of what JET actually is and it's relationship to Access. Show quoteHide quote "Paul Clement" <UseAdddressAtEndofMess***@swspectrum.com> wrote in message news:tt4t5159pc0f402duellmnokevfoi6i482@4ax.com... > On Wed, 13 Apr 2005 23:26:23 -0400, "Scott M." <s-mar@nospam.nospam> > wrote: > > ¤ Uh, no it's not what you said at all. And, most importantly, if you read > ¤ this documentation you will see that the terms MS Access and JET are NOT > ¤ used interchangeably. In fact, throughout the article, Access is > referred > ¤ to as the "Microsoft Access user interface". > ¤ > > Yes, but in other articles and documentation it is not. > > http://tinyurl.com/6acob > > > Paul > ~~~~ > Microsoft MVP (Visual Basic) On Thu, 14 Apr 2005 12:33:58 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ That's because the "other" articles you refer to aren't discussing the ¤ low-level architecture of what is actually storing the data in Access. ¤ What's the point? Access also can make database level modifications w/o Jet. The Jet Database Engine does not completely define the architecture of an Access database. In any event, there would be no Jet Database Engine w/o Access since that is the application from which it originated. ¤ As I've said, in many situations the term "Access Database" is just fine to ¤ convey the meaning of what you are trying to say. What we are discussing is ¤ completely different than those high level discussions (such as the ones ¤ returned by your search). No actually that was never the discussion. The discussion involved a response to aatcbbtcc***@yahoo.com who claimed that an .mdb file is not an Access file. ¤ ¤ Just because I use 2 words interchangeable doesn't mean that they are the ¤ same thing technically. For example, in the OO world, the terms "object" ¤ and "class" are often interchanged and for many discussions that's fine. ¤ But there is a world of difference between what an "object" actually is vs. ¤ what a "class" actually is. ¤ ¤ The article I've provided is specifically about the low-level understanding ¤ of what JET actually is and it's relationship to Access. Don't think I follow where you are going with this. Paul ~~~~ Microsoft MVP (Visual Basic) > ¤ As I've said, in many situations the term "Access Database" is just fine No actually here is what aatcbbtcc***@yahoo.com said:> to > ¤ convey the meaning of what you are trying to say. What we are > discussing is > ¤ completely different than those high level discussions (such as the ones > ¤ returned by your search). > > No actually that was never the discussion. The discussion involved a > response to > aatcbbtcc***@yahoo.com who claimed that an .mdb file is not an Access > file. "Access is *not* a database." He didn't say that an .mdb is not an Access file. My comments here and earlier have been part of the discussion.. Is Access = database or is .mdb=database? Most of the time and in most situations it's fine to say yes beacuse we all know what is trying to be said. But at low-levels it isn't correct to say that Access is the database and the .mdb is the database. Access is a GUI to BOTH the raw data as well as Access-specific data (reports, forms, VBA, etc.). The raw data is stored in the JET database, which Access wraps. Show quoteHide quote > ¤ Just because I use 2 words interchangeable doesn't mean that they are Hmmm, the same place I've been all along :). Did you read the article?> the > ¤ same thing technically. For example, in the OO world, the terms > "object" > ¤ and "class" are often interchanged and for many discussions that's fine. > ¤ But there is a world of difference between what an "object" actually is > vs. > ¤ what a "class" actually is. > ¤ > ¤ The article I've provided is specifically about the low-level > understanding > ¤ of what JET actually is and it's relationship to Access. > > Don't think I follow where you are going with this. On Fri, 15 Apr 2005 11:10:38 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ > ¤ As I've said, in many situations the term "Access Database" is just fine ¤ > to ¤ > ¤ convey the meaning of what you are trying to say. What we are ¤ > discussing is ¤ > ¤ completely different than those high level discussions (such as the ones ¤ > ¤ returned by your search). ¤ > ¤ > No actually that was never the discussion. The discussion involved a ¤ > response to ¤ > aatcbbtcc***@yahoo.com who claimed that an .mdb file is not an Access ¤ > file. ¤ ¤ No actually here is what aatcbbtcc***@yahoo.com said: ¤ ¤ "Access is *not* a database." ¤ ¤ He didn't say that an .mdb is not an Access file. My comments here and ¤ earlier have been part of the discussion.. Yes he did: >> I suspect your mistake is in believing that an MDB file is an *Access*file. It is not - it is a *Jet* file, in which Access is able to store its own things (in addition to the standard Jet things). << ¤ Most of the time and in most situations it's fine to say yes beacuse we all ¤ know what is trying to be said. But at low-levels it isn't correct to say ¤ that Access is the database and the .mdb is the database. Access is a GUI ¤ to BOTH the raw data as well as Access-specific data (reports, forms, VBA, ¤ etc.). The raw data is stored in the JET database, which Access wraps. ¤ For the last time...Access can operate on the database file directly. It is not a wrapper. Does Word wrap a .doc file? Does Excel wrap an .xls file? As I questioned in my other post, do we now call .doc and .xls OLE Structure Storage files instead of Word and Excel files because that is the API which is employed? ¤ > ¤ Just because I use 2 words interchangeable doesn't mean that they are ¤ > the ¤ > ¤ same thing technically. For example, in the OO world, the terms ¤ > "object" ¤ > ¤ and "class" are often interchanged and for many discussions that's fine. ¤ > ¤ But there is a world of difference between what an "object" actually is ¤ > vs. ¤ > ¤ what a "class" actually is. ¤ > ¤ ¤ > ¤ The article I've provided is specifically about the low-level ¤ > understanding ¤ > ¤ of what JET actually is and it's relationship to Access. ¤ > ¤ > Don't think I follow where you are going with this. ¤ ¤ Hmmm, the same place I've been all along :). Did you read the article? ¤ You may want to consider other sources beyond that article. Especially if you're simply going to ignore the fact that the Jet Database Engine provides only a subset of the functionality that is supported for an Access database. That is a technical fact that cannot be disputed. Paul ~~~~ Microsoft MVP (Visual Basic)
Show quote
Hide quote
> ¤ No actually here is what aatcbbtcc***@yahoo.com said: My comments have all pertained to the "Access is *not* a database" remark.> ¤ > ¤ "Access is *not* a database." > ¤ > ¤ He didn't say that an .mdb is not an Access file. My comments here and > ¤ earlier have been part of the discussion.. > > Yes he did: > >>> > I suspect your mistake is in believing that an MDB file is an *Access* > file. It is not - it is a *Jet* file, in which Access is able to store > its own things (in addition to the standard Jet things). > << > For the last time...Access can operate on the database file directly. It Well, for the last time, yes Access does wrap the JET data and provides a UI > is not a wrapper. to that JET data. Microsoft say so much in the article I've provided. >Does Word wrap a .doc file? Does Excel wrap an .xls file? Your comments keep coming back to does the product wrap it's own file extension format file. I have not framed my comments in this way, so I don't believe we are discussing the same thing. As I've said over and over: Access's .mdb file format contains a JET database as well as Access specific items. In this way, Access wraps the JET database. This is the reason you can programmatically connect to an .mdb file and use the JET database contained within it with standard JET DAO's. > As I questioned in my other post, do we now call .doc and .xls OLE I don't know. Do we? My point has been all along, that most of the time > Structure Storage files instead > of Word and Excel files because that is the API which is employed? (99.9%), you can call it whatever you like. But when splitting hairs, you should call it what it is. Now, is OLE a data storage paradigm? No, it is a broad term regarding a set of interfaces that some object needs to provide to be OLE compliant. An apple can be bitten into and so can a bananna, but that doesn't make them both apples. > You may want to consider other sources beyond that article. Especially if You're absolutely correct and it has been my point all along! I haven't > you're simply going to > ignore the fact that the Jet Database Engine provides only a subset of the > functionality that is > supported for an Access database. That is a technical fact that cannot be > disputed. been ignoring this, it's been what I've been saying. An Access file contains a JET database as well as other Access-specific items and wraps it all up into an .mdb. The article is Microsoft's documentation on JET. What better article is there to discuss JET? Scott,
> An apple can be bitten into and so can a bananna, but that doesn't make Exactly they both are fruit. Access is not SQL server however they both > them both apples. provide the developer database facilities, although there is maybe as much difference in that as in a banana and an apple. However that does not stop by that, using the Jet facilities you can use as well an Excell spreadsheet as a database. I think that you did describe it with this very well. Cor Way to change the topic into something it's not Cor!
My question wasn't "are they both fruit", my question was "are they both apples". I'm a human and so are you, but we are not both the SAME human. You've taken something I've written out of context and gone on to write about something very different from what I'm talking about (again, as usual). Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:%23Ujm2ydQFHA.3404@TK2MSFTNGP12.phx.gbl... > Scott, > >> An apple can be bitten into and so can a bananna, but that doesn't make >> them both apples. > > Exactly they both are fruit. Access is not SQL server however they both > provide the developer database facilities, although there is maybe as much > difference in that as in a banana and an apple. > > However that does not stop by that, using the Jet facilities you can use > as well an Excell spreadsheet as a database. > > I think that you did describe it with this very well. > > Cor > > Scott,
Somebody acting in this business would never ask if "true" can be the same as "false". However, it are both conditions that can exist. When you ask if an apple is not a banana (I assume that is what you mean with what you wrote as bananna, because I don't know that word in English), I answered you that they are both fruit. However better than answering you directly on the question if Access is a database, I can show you this link. http://en.wikipedia.org/wiki/Database Cor And, again you are answering questions that were never asked.
I'm sorry Cor, I have no more time to waste on you. Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:eF9cALeQFHA.248@TK2MSFTNGP15.phx.gbl... > Scott, > > Somebody acting in this business would never ask if "true" can be the same > as "false". However, it are both conditions that can exist. > > When you ask if an apple is not a banana (I assume that is what you mean > with what you wrote as bananna, because I don't know that word in > English), I answered you that they are both fruit. > > However better than answering you directly on the question if Access is a > database, I can show you this link. > > http://en.wikipedia.org/wiki/Database > > Cor > Scott,
>> However better than answering you directly on the question if Access is a I know that you think that you are a superior person. You have often showed >> database, I can show you this link. >> >> http://en.wikipedia.org/wiki/Database > And, again you are answering questions that were never asked. > > I'm sorry Cor, I have no more time to waste on you. > that in these newsgroups. However, I wished that the content of your answers are superior and not exist consequently from telling that somebody write not good English or statements as above when somebody proofs you'r wrong. About that English by the way, you write yourself sentences like beneath. Maybe is it better that you first start learning to write good English before you do those statements. >Your comments keep coming back to does the product wrap it's own file. The way of your superiority style comes back in a sentence on Wikipidi, that I showed you in my last message what is completely on topic of this thread. However, probably not even opened by you. From Wikipidi (The terms database and database management system are sometimes interchanged by students. In the professional argot, a database is always the collection of facts, not the software program.) Cor > I know that you think that you are a superior person. You have often I never said that once. What I've said to you in many previous posts is > showed that in these newsgroups. there for anyone to read. You contradict yourself quite often and you make comments that don't have anything to do with the topic at hand. > However, I wished that the content of your answers are superior and not What proof have you provided of anything (other than you've misquoted me)? > exist consequently from telling that somebody write not good English or > statements as above when somebody proofs you'r wrong. You haven't provided any proof because you keep answering questions that were not being discussed. > About that English by the way, you write yourself sentences like beneath. I told you that I wasn't trying to insult you by telling you that your > Maybe is it better that you first start learning to write good English > before you do those statements. English is difficult to understand. I find it rather odd that someone who has trouble writing English could have the ability to determine what is and what isn't written in proper English. It's obvious, at this point Cor, that you just feel a bit hurt and want to sling insults. I'm sorry if I have offended you, but if I can't understand something you've written because the English is so incorrect, I'm going to tell you that. > The way of your superiority style comes back in a sentence on Wikipidi, But we are NOT discussing the general terms database and database management > that I showed you in my last message what is completely on topic of this > thread. However, probably not even opened by you. > > From Wikipidi > > (The terms database and database management system are sometimes > interchanged by students. In the professional argot, a database is always > the collection of facts, not the software program.) > system here! This is my point! Don't you get it? We are discussing the very specific JET software and the Access software. Obviously, if you can't see the difference, then you've proven my point that you keep posting irrelevant information that does not pertain to this discussion. My bottom line with you Cor, is that you'd rather argue then simply READ what is being presented. You'd rather sling insults than stay on topic. Scott,
Why are you involved forever in the longest discussion threads and not only with me? I mostly try to quit discussions with you because you are jumping form subject to subject to proof that you are right and are not able to keep it with the main topic. Those long threads can have two reasons: You are not stating your arguments well; you are not able to read the things people write. This is not only with me, you have in this thread a long discussion with Paul, while you obvious don't understand what he is writing, while it is so clear for me almost from his second message. Therefore, I don't blame you for that. The only thing I blame you is that you put this as failures from other people and do not check if it is maybe the result of what you are doing yourself. In addition, I do not say with this that I write it forever correct and that it cannot better. Cor LOL: Read what you've written and apply it to yourself. Don't speak for
others. Just try to speak well for yourself. No one has ever accused me of jumping from one topic to another. You are the one posting irrelevant links to webopedias on the definition of what a database is when that is not what was being discusses. You are the one pointing out differences between a database and a RDMS when that is not what is being discussed. I have been talking about JET and its relationship to Access, period. No topic jumping. Ask yourself what is more likely: me (an English speaking person) not understanding other posts written in English by other English speaking people or you not understanding posts written in English by English speaking people. Be honest. What do you think? Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:O0DZy8qQFHA.3196@TK2MSFTNGP12.phx.gbl... > Scott, > > > > Why are you involved forever in the longest discussion threads and not > only with me? > > I mostly try to quit discussions with you because you are jumping form > subject to subject to proof that you are right and are not able to keep it > with the main topic. > > Those long threads can have two reasons: > > You are not stating your arguments well; > you are not able to read the things people write. > > This is not only with me, you have in this thread a long discussion with > Paul, while you obvious don't understand what he is writing, while it is > so clear for me almost from his second message. > > > > Therefore, I don't blame you for that. The only thing I blame you is that > you put this as failures from other people and do not check if it is maybe > the result of what you are doing yourself. > > > > In addition, I do not say with this that I write it forever correct and > that it cannot better. > > Cor > > > > Scott,
In my opinion is your problem that you have to short knowledge and start writing. For 90% of the Dutch speaking people (from the Netherlands, Belgium and Suriname) (those 10% are the elder ones)speaks as well English. It is in the Netherlands a second natural language (I write this not for Belgium and Suriname because in those countries are official second natural languages, however there it is probably the same). Most children in the Netherlands can understand, speak, and read English when they are about 12. As I once heard on BBC (That is the British Broad Casting Organization) where is spoken in my opinion real good English, telling that the Dutch English an English Dialect. However, most of us do normally seldom write in English, so that goes mostly with a lot of errors especially when we start or start again with it. Maybe strange for you, however read next time something before you start writing. Cor On Fri, 15 Apr 2005 12:45:01 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ > ¤ No actually here is what aatcbbtcc***@yahoo.com said:¤ > ¤ ¤ > ¤ "Access is *not* a database." ¤ > ¤ ¤ > ¤ He didn't say that an .mdb is not an Access file. My comments here and ¤ > ¤ earlier have been part of the discussion.. ¤ > ¤ > Yes he did: ¤ > ¤ >>> ¤ > I suspect your mistake is in believing that an MDB file is an *Access* ¤ > file. It is not - it is a *Jet* file, in which Access is able to store ¤ > its own things (in addition to the standard Jet things). ¤ > << ¤ ¤ My comments have all pertained to the "Access is *not* a database" remark. ¤ Mine didn't. Access is an application that operates upon Access databases. An .mdb file is a legitimate native file type that is specific to this the program. ¤ > For the last time...Access can operate on the database file directly. It ¤ > is not a wrapper. ¤ ¤ Well, for the last time, yes Access does wrap the JET data and provides a UI ¤ to that JET data. Microsoft say so much in the article I've provided. ¤ It's not a wrapper. It makes calls to a database engine API in order to perform certain database operations to support functionality supported by the application. It also makes calls directly to the database - there is no wrapping involved. DAO is a wrapper which exposes Jet functionality. Access is not. ¤ >Does Word wrap a .doc file? Does Excel wrap an .xls file? ¤ ¤ Your comments keep coming back to does the product wrap it's own file ¤ extension format file. I have not framed my comments in this way, so I ¤ don't believe we are discussing the same thing. As I've said over and over: ¤ Access's .mdb file format contains a JET database as well as Access specific ¤ items. In this way, Access wraps the JET database. This is the reason you ¤ can programmatically connect to an .mdb file and use the JET database ¤ contained within it with standard JET DAO's. ¤ Nope. Access can use DAO, but it also has integrated database functionality. It has to in order to support certain features such as executing VBA code routines used in SQL or Access QueryDefs. Jet does not support this feature. ¤ > As I questioned in my other post, do we now call .doc and .xls OLE ¤ > Structure Storage files instead ¤ > of Word and Excel files because that is the API which is employed? ¤ ¤ I don't know. Do we? My point has been all along, that most of the time ¤ (99.9%), you can call it whatever you like. But when splitting hairs, you ¤ should call it what it is. Now, is OLE a data storage paradigm? No, it is ¤ a broad term regarding a set of interfaces that some object needs to provide ¤ to be OLE compliant. An apple can be bitten into and so can a bananna, but ¤ that doesn't make them both apples. ¤ No, it is an API and data storage mechanism just as Jet is. ¤ > You may want to consider other sources beyond that article. Especially if ¤ > you're simply going to ¤ > ignore the fact that the Jet Database Engine provides only a subset of the ¤ > functionality that is ¤ > supported for an Access database. That is a technical fact that cannot be ¤ > disputed. ¤ ¤ You're absolutely correct and it has been my point all along! I haven't ¤ been ignoring this, it's been what I've been saying. An Access file ¤ contains a JET database as well as other Access-specific items and wraps it ¤ all up into an .mdb. The article is Microsoft's documentation on JET. What ¤ better article is there to discuss JET? ¤ Access neither wraps nor contains a database. Paul ~~~~ Microsoft MVP (Visual Basic) > It's not a wrapper. It makes calls to a database engine API in order to Well, I guess we've finally come to it. JET is not an API. JET is the > perform certain database > operations to support functionality supported by the application. It also > makes calls directly to > the database - there is no wrapping involved. database type. If you would just READ the Microsoft documentation on JET we wouldn't be going round and round on this. > DAO is a wrapper which exposes Jet functionality. Access is not. No, once again you have it backwards. DAO is an API, Access is a wrapper of JET. > No, it is an API and data storage mechanism just as Jet is. So, now you admit that JET is a data storage mechanism...you mean like .... a DATABASE? > Access neither wraps nor contains a database. And now you are saying that Access doesn't even contain a database? Hmmm.Hey, good luck to you. This sub-thread was always a matter of splitting hairs and I don't have too many left to split. I can't help if you won't even read the specs. On Fri, 15 Apr 2005 16:43:06 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ ¤ > It's not a wrapper. It makes calls to a database engine API in order to ¤ > perform certain database ¤ > operations to support functionality supported by the application. It also ¤ > makes calls directly to ¤ > the database - there is no wrapping involved. ¤ ¤ Well, I guess we've finally come to it. JET is not an API. JET is the ¤ database type. If you would just READ the Microsoft documentation on JET we ¤ wouldn't be going round and round on this. ¤ Yes, Jet is an API. Microsoft does not publicly disclose ¤ > DAO is a wrapper which exposes Jet functionality. Access is not. ¤ ¤ No, once again you have it backwards. DAO is an API, Access is a wrapper of ¤ JET. ¤ ¤ > No, it is an API and data storage mechanism just as Jet is. ¤ ¤ So, now you admit that JET is a data storage mechanism...you mean like .... ¤ a DATABASE? ¤ ¤ > Access neither wraps nor contains a database. ¤ ¤ And now you are saying that Access doesn't even contain a database? Hmmm. ¤ ¤ Hey, good luck to you. This sub-thread was always a matter of splitting ¤ hairs and I don't have too many left to split. I can't help if you won't ¤ even read the specs. ¤ Paul ~~~~ Microsoft MVP (Visual Basic) On Fri, 15 Apr 2005 16:43:06 -0400, "Scott M." <s-mar@nospam.nospam> wrote: ¤ ¤ > It's not a wrapper. It makes calls to a database engine API in order to ¤ > perform certain database ¤ > operations to support functionality supported by the application. It also ¤ > makes calls directly to ¤ > the database - there is no wrapping involved. ¤ ¤ Well, I guess we've finally come to it. JET is not an API. JET is the ¤ database type. If you would just READ the Microsoft documentation on JET we ¤ wouldn't be going round and round on this. ¤ Don't believe everything you read and don't read into everything you believe. Jet *is* an API that is not publicly disclosed by Microsoft. ¤ > DAO is a wrapper which exposes Jet functionality. Access is not. ¤ ¤ No, once again you have it backwards. DAO is an API, Access is a wrapper of ¤ JET. ¤ DAO is also an API - it's a COM based API. ¤ > No, it is an API and data storage mechanism just as Jet is. ¤ ¤ So, now you admit that JET is a data storage mechanism...you mean like .... ¤ a DATABASE? ¤ ¤ > Access neither wraps nor contains a database. ¤ ¤ And now you are saying that Access doesn't even contain a database? Hmmm. ¤ Right. There is no containing. It's file I/O between the application and the database. ¤ Hey, good luck to you. This sub-thread was always a matter of splitting ¤ hairs and I don't have too many left to split. I can't help if you won't ¤ even read the specs. ¤ I appreciate your concern and thanks for sharing your knowledge Scott. But I've worked with Access for over a decade now and I'm fairly confident that those I talk to at Microsoft know their product. ;-) Paul ~~~~ Microsoft MVP (Visual Basic) I agree, and apologies. I do understand the difference between SQL
(Structured Query Language) and an SQL Server (which provides a database environment in which SQL is used to access and manipulate data). And I also argree that MS Access as a product is not a database, it's an IDE for developing a DB front end. However, I think everyone that has replied to my post understood what I was talking about (I hope) Either way, I'll try to be more careful with my wording. Cheers Lee <aatcbbtcc***@yahoo.com> wrote in message Show quoteHide quote news:1113106897.126133.12200@o13g2000cwo.googlegroups.com... > Haven't read all the replies, so apologies if this has aready been > said: > > 1. Access is *not* a database. It is a front-end IDE. The underlying > database for Access is normally MS Jet, a comlementary but completely > seperate product. You can have an Access front-end with any compatible > database including but not limited to Jet, Oracle, SQL Server, etc. > Conversely, you can use a Jet database with any complementary front-end > including but not limited to Access, VB, etc. > > 2. SQL also is *not* a database. SQL is a data access language which is > used in many databases, including but not limited to Jet, SQL Server, > Oracle, etc. > > IOW, please let's get the terminolgy right :-) > > HTH, > TC > lgbjr,
>And I also agree that MS Access as a product is not a database, it's an IDE As I wrote in my previous message this is not true, I have the idea you are >for developing a DB front end. talking about the MS office Access product. You can create an access database using ADO in your program as a part of your development. Cor Cor,
I think this is a symantics issue. I will agree that throughout the user populance, many people refer to Access, MS Access, an Access DB, etc. as being a database. While this has been / is acceptable for most people, I believe what TC said is technically correct. Most people open MS Access, create some tables, queries, forms, modules, etc. and the language used to drive the front end is VBA (forms, modules, etc). Most are unaware that the actual DB engine is not Access (as there's no such thing), it's Jet (by default). After loading MSDE, since it doesn't have a GUI, I am using MS Access, via an ADP project, to make modifications to the MSDE DB (SQL Server DB). If MS Access were, as you're implying, a database engine, you wouldn't be able to change database engines in the product. Therefore, MS Access should really be thought about and talked about as an IDE that supports several DB engines (similar to VS.NET being an IDE that supports several programming languages). Again, I believe this is a symantics issue. Everyone knows/knew what I was talking about, but, from now on, when I catch myself refering to an Access DB, I'll replace that with a Jet DB with a front end built in MS Access, or whatever DB engine I happen to be using. Of course, if I talk to my clients about a Jet DB, I'll just get blank stares and questions about what happened to the Access DB. ;-) Cheers Lee Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:O7KASNaPFHA.164@TK2MSFTNGP12.phx.gbl... > lgbjr, > >>And I also agree that MS Access as a product is not a database, it's an >>IDE for developing a DB front end. > > As I wrote in my previous message this is not true, I have the idea you > are talking about the MS office Access product. You can create an access > database using ADO in your program as a part of your development. > > Cor > Microsoft's use of the term "Access Database" in that article, is
incorrect. If I happened to mis-spell my own name, that would not make the mis-spelling correct! HTH, TC Cor Ligthert wrote:
> You can create an access database using That is not an Access database. It is a Jet database. It does not> ADO in your program as a part of your > development. require MS Access to be present (before, now, or in the future) on the PC. HTH, TC Cor you're wrong.
TC you're being pedantic. I hope neither of you are customer facing for your respective firms. Richard <aatcbbtcc***@yahoo.com> wrote in message Show quoteHide quote news:1113193415.690790.115480@g14g2000cwa.googlegroups.com... > > Cor Ligthert wrote: > > > You can create an access database using > > ADO in your program as a part of your > > development. > > > That is not an Access database. It is a Jet database. It does not > require MS Access to be present (before, now, or in the future) on the > PC. > > HTH, > TC > Richard,
>Cor Ligthert wrote: Will you explain what is wrong in my statement?>> You can create an access database using > >ADO in your program as a part of your > >development. > Cor you're wrong. > TC you're being pedantic. > I hope neither of you are customer facing for your respective firms. > Cor JT already has.
Show quoteHide quote "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message news:u50JodmPFHA.2136@TK2MSFTNGP14.phx.gbl... > Richard, > > >Cor Ligthert wrote: > > >> You can create an access database using > > >ADO in your program as a part of your > > >development. > > > Cor you're wrong. > > TC you're being pedantic. > > I hope neither of you are customer facing for your respective firms. > > > > Will you explain what is wrong in my statement? > > Cor > > Richard,
No he did not on my question too you to explain why you wrote that this statement from me is not true. >> You can create an access database using At least you should tell why?> >ADO in your program as a part of your > >development. Cor "Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message Nope. Im currently eating ice cream with a fork which seems much morenews:OiLQMxmPFHA.2584@TK2MSFTNGP15.phx.gbl... > Richard, > > No he did not on my question too you to explain why you wrote that this > statement from me is not true. > > >> You can create an access database using > > >ADO in your program as a part of your > > >development. > > At least you should tell why? interesting than continuing with this thread. If you dont get it then thats fine, i really dont care either way. Check out MSDN or alternatively try Access Help Files. Richard Richard Myers wrote:
> I hope neither of you are customer facing for your respective firms. What an arrogant comment. This is a technical discussion forum, not ashop front counter. I believe that technical accuracy is important in a technical forum. You obviousy disagree. I leave readers to judge for themselves. Goodbye. TC 
Other interesting topics
arraylist copy
Why do we need Namespace and Module? Easiest way to generate XML in VB.NET Excaping recursive functions How can I let the internet explorer start to navigate in the same windwo? Multi-dimensional array with variable number of elements in last dimension Legacy Client <--> DotNet Listener Possible values of DTE.ActiveDocument.Kind ? How do you force a thread to run on a specific processor? TAB (key) to next control instead of next column (in datagrid) |
|||||||||||||||||||||||
