If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
Access or Visual Studio?
Hi, I'm a bit confused ... when would I rather write an database
application using MS Access and Visual Basic and when (and why) would I rather write it using Visual Studio .Net? Is it as easy in Visual Studio to create reports and labels as it's in Access?` The advantage of VS.net is that not every user needs Access, right? And that would eliminate the Access version problem as well I guess. I've both done stuff in Access as well as asp.net Thanks! |
#2
|
|||
|
|||
"Jerome" wrote in message
... Hi, I'm a bit confused ... when would I rather write an database application using MS Access and Visual Basic and when (and why) would I rather write it using Visual Studio .Net? Is it as easy in Visual Studio to create reports and labels as it's in Access?` The advantage of VS.net is that not every user needs Access, right? And that would eliminate the Access version problem as well I guess. I've both done stuff in Access as well as asp.net Thanks! Access is a vastly superior development platform for database applications: the cost of development is far lower, and it has wonderful database-centric features like linked subforms and continuous forms. The only reason to use anything other than Access to build a database application is if you want it on the internet, which is something that you just can't do with Access. Even if you have a large user population or demanding security/resilience requirements, it's still best to use Access, linked to a sever database engine such as SQL Server. If you buy the Office Developer Edition, or whatever Microsoft is calling it these days, you can freely distribute a run-time version of Access so that you don't need to buy Access for all your users. |
#3
|
|||
|
|||
Brian,
Access is a vastly superior development platform for database applications: the cost of development is far lower, and it has wonderful database-centric features like linked subforms and continuous forms. The only reason to use anything other than Access to build a database application is if you want it on the internet, which is something that you just can't do with Access. Even if you have a large user population or demanding security/resilience requirements, it's still best to use Access, linked to a sever database engine such as SQL Server. How large is your team to build simultanisly applications with? And how you have reusability implemented with that? Cor |
#4
|
|||
|
|||
I've worked with teams of as many as 6 developers building large
applications for small numbers of users. With competent project management there were no problems at all. With incompetence, even 2 developers is 2 too many. As far as reuseability goes, I can't speak for others, but most of my code (maybe 75 to 80%) is reuseable. -- Arvin Meyer, MCP, MVP Microsoft Access Free Access downloads: http://www.datastrat.com http://www.mvps.org/access "Cor Ligthert" wrote in message ... Brian, Access is a vastly superior development platform for database applications: the cost of development is far lower, and it has wonderful database-centric features like linked subforms and continuous forms. The only reason to use anything other than Access to build a database application is if you want it on the internet, which is something that you just can't do with Access. Even if you have a large user population or demanding security/resilience requirements, it's still best to use Access, linked to a sever database engine such as SQL Server. How large is your team to build simultanisly applications with? And how you have reusability implemented with that? Cor |
#5
|
|||
|
|||
I would disagree with you on many points.
1. Access is a horrible platform for large databases. While it can get to a rather large size, it is a file based DB, which means perf degrades horribly. I would say 50MB is a good theoretical max, although I have seen Access DBs in the ridiculous range. 2. Access is great for single developers, but bad for team development. It is difficult to impossible to get a team working on the same solution, unless Access is merely a data repository. 3. Access creates monolithic applications, which means there is little flexibility in distributing the work as your company grows. Access certainly fits a niche. It has a wonderful designer and allows you to leverage your work with forms, queries, reports, etc. Much of the work can be done without a huge amount of code. But, you pay a price, as you lock yourself into the Access solution. If you later outgrow, you end up rewriting everything. I am not knocking Access, as it is a great product, but it definitely has its limitations. Whether Jerome should use Access or not depends on his final goal. Lots of growth - Access as a backend only. Not wise to lock into to Access forms. Speed of getting product to market - Access may be the best option, if Jerome is an Access developer Application needs to scale - Access as backend, with plans on scaling data up later (or MSDE from start) There are other items to consider, of course. -- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA *********************************************** Think outside the box! *********************************************** "Brian" wrote in message ... "Jerome" wrote in message ... Hi, I'm a bit confused ... when would I rather write an database application using MS Access and Visual Basic and when (and why) would I rather write it using Visual Studio .Net? Is it as easy in Visual Studio to create reports and labels as it's in Access?` The advantage of VS.net is that not every user needs Access, right? And that would eliminate the Access version problem as well I guess. I've both done stuff in Access as well as asp.net Thanks! Access is a vastly superior development platform for database applications: the cost of development is far lower, and it has wonderful database-centric features like linked subforms and continuous forms. The only reason to use anything other than Access to build a database application is if you want it on the internet, which is something that you just can't do with Access. Even if you have a large user population or demanding security/resilience requirements, it's still best to use Access, linked to a sever database engine such as SQL Server. If you buy the Office Developer Edition, or whatever Microsoft is calling it these days, you can freely distribute a run-time version of Access so that you don't need to buy Access for all your users. |
#6
|
|||
|
|||
"Cowboy (Gregory A. Beamer)" wrote in message ... I would disagree with you on many points. 1. Access is a horrible platform for large databases. While it can get to a rather large size, it is a file based DB, which means perf degrades horribly. I would say 50MB is a good theoretical max, although I have seen Access DBs in the ridiculous range. 2. Access is great for single developers, but bad for team development. It is difficult to impossible to get a team working on the same solution, unless Access is merely a data repository. 3. Access creates monolithic applications, which means there is little flexibility in distributing the work as your company grows. Access certainly fits a niche. It has a wonderful designer and allows you to leverage your work with forms, queries, reports, etc. Much of the work can be done without a huge amount of code. But, you pay a price, as you lock yourself into the Access solution. If you later outgrow, you end up rewriting everything. I am not knocking Access, as it is a great product, but it definitely has its limitations. Whether Jerome should use Access or not depends on his final goal. Lots of growth - Access as a backend only. Not wise to lock into to Access forms. Speed of getting product to market - Access may be the best option, if Jerome is an Access developer Application needs to scale - Access as backend, with plans on scaling data up later (or MSDE from start) There are other items to consider, of course. -- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA *********************************************** Think outside the box! *********************************************** 1. "it is a file based DB" You are talking specifically here about Jet databases. What you say is not correct, I have live Access/Jet applications running just fine for years at database sizes approaching 1Gb. Not a problem at all, you just need to design 'em right. What IS ridiculous is your suggestion of a theoretical maximum of 50Mb, and I cannot imagine what you base such a silly claim on. Nonetheless, if you do expect to exceed the capabilities of a Jet database (which is possible in many ways, not just in terms of size e.g. you may have security/resilience requirements which Jet simply can't meet) then (as I believe I mentioned) Access makes an excellent client to server database engines such as SQL Server or Oracle. 2. "Access is great for single developers, but bad for team development. It is difficult to impossible to get a team working on the same solution, unless Access is merely a data repository. Sorry, you lost me here, it's perfectly straightforward to have different people working on different front-end areas and then to integrate them. 3. "Access creates monolithic applications, which means there is little flexibility in distributing the work as your company grows." You are going to have to explain that one a bit better. Access as a client to a server database engine is every bit as scalable as any two-tier client-server architecture using the same database engine. You seem to be stuck on Jet again. 4. "But, you pay a price, as you lock yourself into the Access solution. If you later outgrow, you end up rewriting everything." See above re Access as a client to server database engines. 5. "I am not knocking Access, as it is a great product, but it definitely has its limitations. Whether Jerome should use Access or not depends on his final goal" Jet, whilst an excellent product for the right purpose, certainly does have limitations. Access as a client to a server database engine is limited only by the server (unless you are big enough to need a three-or-more-tier architecture, or you are looking to distribute your app across the internet which I already said Access is no good at). 6. "Not wise to lock into to Access forms." How is that any less wise than locking in to, say, dotnet Windows Forms? You've got to build your clients in something, and, as soon as you make that decision, hey presto, you are locked in. 7. "Speed of getting product to market" What's your point here? All other things being equal, a database application will take, quite literally, a fraction of the time to develop in Access as compared to Windows Forms in dotnet. |
#7
|
|||
|
|||
"Cowboy (Gregory A. Beamer)" wrote in
message ... I would disagree with you on many points. 1. Access is a horrible platform for large databases. While it can get to a rather large size, it is a file based DB, which means perf degrades horribly. I would say 50MB is a good theoretical max, although I have seen Access DBs in the ridiculous range. Depends upon how you design it. I currently have a client running a split ACCESS database product over a LAN, where the backend file is almost 100MB, with up to 15 concurrent users. -- Ken Snell MS ACCESS MVP |
#8
|
|||
|
|||
"Cowboy (Gregory A. Beamer)" wrote in
message ... I would disagree with you on many points. 1. Access is a horrible platform for large databases. While it can get to a rather large size, it is a file based DB, which means perf degrades horribly. I would say 50MB is a good theoretical max, although I have seen Access DBs in the ridiculous range. I have seen them in the ridiculous range too, and they run fine if well designed. I had a client several years ago that experienced her first corruption of one of the 80 Access 2.0 databases she had hung off a single front end. Once I fixed it she went happily on. Size: 30GB 2. Access is great for single developers, but bad for team development. It is difficult to impossible to get a team working on the same solution, unless Access is merely a data repository. As I said elsewhere, I've worked with a team of 6. I know of other developers that use Source-safe, but I've never found it necessary. 3. Access creates monolithic applications, which means there is little flexibility in distributing the work as your company grows. I've not had any problems, my databases are distributed by the server. As a user logs on he gets the front-ends he needs. -- Arvin Meyer, MCP, MVP Microsoft Access Free Access downloads: http://www.datastrat.com http://www.mvps.org/access |
#9
|
|||
|
|||
"Cowboy (Gregory A. Beamer)" wrote in
message news:% 1. Access is a horrible platform for large databases. While it can get to a rather large size, it is a file based DB, which means perf degrades horribly. Actually, in single user mode a JET based file application is faster then sql server. I am going to repeat this again just in case you think this was a type-o. The JET engine is faster then sql server!!! Anywhere from 30 to 200% faster. Remember, sql server has a ton of overhead, and JET simply scrapes data right off of the disk drive. Further, you seem to imply that you don't have a choice of what data engine to use. Remember, ms-access is just a ide. It is a ide like visual studio. You write code, you build forms, you build class objects. The data engine you use with ms-access can be JET, or it can be sq server. There are companies out there with 1000 simultaneous users of ms-access all hitting the SAME database. The fact of the matter sql server runs no different if you code in c++, or use ms-access (they both are using the same oleDB library). You can scale the applications to 100's of users in all cases when you use sql server. However, the fact remains that JET grabs records faster then sql server (we taking same hardware....no network involved here). In fact, to normally grab data from sql server you still (on a local host) have to grab data through a socket connection, and that alone is going to slow things down (further, sql serve has to wrap most things in a transaction, and also use timestamp fields to ensure things are ATOMIC). 2. Access is great for single developers, but bad for team development. It is difficult to impossible to get a team working on the same solution, unless Access is merely a data repository. Remember, the coding environment in ms-access is the same as VB6. You can create calls objects in ms-access, and this does help in the re-usability area. Also, Visual Source Safe also works with ms-access also. So, I am just point out that ms-access is not a database at all, and all of the development trappings such as using visual source safe etc does work with ms-access. If you want to use VSS, and have users check in/ check out code, the you can do so with ms-access. So, I think for this discussion it is impart to distinguish between the database part, and the IDE that ms-access is. The database part that you use with ms-access can be the file based JET engine, or you can use sql server. Having said the above, as a project does get larger, then coding approaches used, and things like considering a 3 tried approach to the application does favor using Visual studio, source code control, and a language like .net, or even c++. However, to use c++ for writing a average business application is kind like writing some calculations in assembler to add a few numbers when you got Excel sitting on your desktop. However, for real-time fluid calculations that c, or assembler would be a good choice. Note that the same arguments can be made against VB6 in this regards of project size. So, yes, I do agree with you that project size is most certainly a consideration here. I have to agree that as a project scales to MANY developers, then the fact of reduced development speed becomes less of a factor, and things like using a OO approach in terms of design and modeling code most certainly does become an advantage in other IDE's. (.net for example!!) However, it also needs pointing out that the MAJORITY of bussing applications written today do NOT HUGELY benefit form the large use of a OO approach. However, more and more business applications do benefit from a general OO approach. With ..net gaining traction in the marketplace, then the OO approach becomes more common. 3. Access creates monolithic applications, which means there is little flexibility in distributing the work as your company grows. This is a interesting aspect. Virtually all ms-access developers now split their code/forms away from the data part. You create what is called a mde in ms-access (essentially a compiled version of the application). This means to update a user, you simply send them the new mde, and they copy it over the old one Since the application has no data..then this works great. In fact, ms-access developers have enjoyed this x-copy development process for years. You now hear today .net developers singing the praise of x-copy development. I just last week deployed a whole version of my software to 5 different companies (and, they were in a different city then me!!). To deploy this new software, all the users had to do was copy the application to their computers..and away they went (I did wrap the mde in a Inno install..and send them a .exe to run). However, this band new "singing" of the praise by .net developers of how you can simply copy the application part to the users computer and it runs has been a feature, and part of the landscape for ms-access developers for a long time. There is no question that many arm-chair ms-access developers make the mistake of not splitting out the code/forms/logic from the data, .but as a general rule, ms-access developers do not keep the data part, and application part as one monolithic application. This decision is not the fault of the ms-access design, but that of the developers using the product. So, while .net users sing the praise of x-copy development and deployment...we had that great feature for years! Access certainly fits a niche. It has a wonderful designer and allows you to leverage your work with forms, queries, reports, etc. Much of the work can be done without a huge amount of code. But, you pay a price, as you lock yourself into the Access solution. If you later outgrow, you end up rewriting everything. The outgrow part you mention has to be defined here. Do you mean the data part, or the application complex part? The data part is easy, you just move the back end data part to Oracle, sql-server, or whatever your favorite data engine tends to be. The application part is a fair issue you bring up. Once again, as a developer I do commonly now use, and built class objects in ms-access. However, you can't use ms-access to build the middle tier in a 3 tiered applications (apparently, there is a com add in for ms-access..but I don't think it is appropriate use here). And, ms-access does support xml, and also has the soap tool kit add-in. With the soap kit, ms-access can now easily consume ..net services. I have to say that the MAJORITY of small business applications written don't need more then a few developers. However, if the product you are crating is to be widely distributed, and you want a reduction in dependencies, and you expect to have a large development team, then ms-access is a weak choice. However, it is VERY difficult to outgrow ms-access in terms of a large database (since you just move the data to a server based product). Once again, I am not saying ms-access should be use for all projects. And,to be fair, ms-access works well in a two tiered approach, but not much well in a 3 tiered approach. However, again, if you only got 30 -200 users, then a two tiered approach (ms-access/sql server back end), then sql server and ms-access will hardly break out a sweat. For larger user counts, and applications with larger amounts of business logic, then better environments most certainly do exist then ms-access. The only question that remains is when to choose what tools for the right job. As always, this is about the right horse for the right course... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada http://www.members.shaw.ca/AlbertKallal |
#10
|
|||
|
|||
Access should be used as a portible database where large amounts of data is not expected.
SQL Server (Oracle, etc.) should be used for rooted databases where potentially large amounts of data will be used. VS.NET is not a database. It can connect to an instance of any ODBC database, and I believe that some (maybe all) versions of VS.NET ship with MSDE version of SQL Server. This is a desktop engine which allows developers to develop database code without having to purchase full versions of the software. If your planning on using the database for a website, Access is viable if there will not be large amounts of data, high performance is not expected in a stressful environment, security roles are not required and the benefits of T-SQL, DTC and Extended Stored Procs are not required. Otherwise, think about purchasing a more robust database server. For the time being, I believe you can use the MSDE version that shipped with VS.NET for development purposes. Hope it helps. -- Dave Sexton ----------------------------------------------------------------------- "Jerome" wrote in message ... Hi, I'm a bit confused ... when would I rather write an database application using MS Access and Visual Basic and when (and why) would I rather write it using Visual Studio .Net? Is it as easy in Visual Studio to create reports and labels as it's in Access?` The advantage of VS.net is that not every user needs Access, right? And that would eliminate the Access version problem as well I guess. I've both done stuff in Access as well as asp.net Thanks! |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Access Error Message when opening database | eah | General Discussion | 3 | January 26th, 2005 10:04 AM |
Images in a database | Franz | General Discussion | 10 | October 7th, 2004 09:35 AM |
Access XP Compared to Access 2003 | Mardene Leahu | New Users | 1 | October 1st, 2004 05:11 AM |
Upload Image | Jason MacKenzie | General Discussion | 1 | September 1st, 2004 04:38 AM |
Error while running Access MDE | Hemil | General Discussion | 2 | June 21st, 2004 01:03 PM |