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
|
|||
|
|||
dotnet windows forms vs. Access
I just wonder if I am wasting my time learning VS 2005.
I've developed in Access for a long time, and seek out advanced work which invariably requires complex unbound data entry forms connected to a MS SQL back end. Taking a hard look and experimenting with dotnet 2.0 and Visual Studio 2005 to see if dotnet Windows forms might be a good alternative for these specific kinds of jobs, so far it doesn't seem so. My impression thus far is it's great for quick and dirty jobs, but not complex ones. What do you guys think? Better to stay with Access and SQL Server or not? Peter |
#2
|
|||
|
|||
dotnet windows forms vs. Access
I assume you are talking about VB.Net and Windows forms. I'm not sure why
you think that it's only for quick and dirty jobs, it's pretty powerful, although a pig to learn. My dislike for VB.Net (and Visual Studio) is such that I have recently been experimenting with Delphi, although I haven't gone far enough yet to be able to recommend it. If you are mainly using unbound forms, forget about Access. Using Access to build unbound forms is like taking a sledgehammer to crack a nut. However, I am curious as to the circumstances in which you feel you need to go unbound. It is rarely necessary in my experience. "PMK" wrote in message ... I just wonder if I am wasting my time learning VS 2005. I've developed in Access for a long time, and seek out advanced work which invariably requires complex unbound data entry forms connected to a MS SQL back end. Taking a hard look and experimenting with dotnet 2.0 and Visual Studio 2005 to see if dotnet Windows forms might be a good alternative for these specific kinds of jobs, so far it doesn't seem so. My impression thus far is it's great for quick and dirty jobs, but not complex ones. What do you guys think? Better to stay with Access and SQL Server or not? Peter |
#3
|
|||
|
|||
dotnet windows forms vs. Access
On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"
wrote: I assume you are talking about VB.Net and Windows forms. Or C#.Net, etc., yes. I'm not sure why you think that it's only for quick and dirty jobs, it's pretty powerful I didn't say only, and it's just a first impression - that is one of the reasons I was asking for other opinions, but it is because you can drag and drop so easily, including data connections - makes it easy to knock off a simple application especially using datagrid type controls, yet I am finding it unwieldy to deal with those very same data controls - datasets, etc., manually. although a pig to learn. My dislike for VB.Net (and Visual Studio) is such What don't _you_ like about VB.net and VS? that I have recently been experimenting with Delphi, although I haven't gone far enough yet to be able to recommend it. If you are mainly using unbound forms, forget about Access. Using Access to build unbound forms is like taking a sledgehammer to crack a nut. However, I am curious as to the circumstances in which you feel you need to go unbound. It is rarely necessary in my experience. I saw your comment about that elsewhere. I don't know why you feel that bound forms is such a huge benefit of Access, but anyway, I use unbound a lot primarily because I find it makes validation so much easier and avoids the complexities of undoing an edit or reversing the addition of a new record, particularly in a sub form. "PMK" wrote in message .. . I just wonder if I am wasting my time learning VS 2005. I've developed in Access for a long time, and seek out advanced work which invariably requires complex unbound data entry forms connected to a MS SQL back end. Taking a hard look and experimenting with dotnet 2.0 and Visual Studio 2005 to see if dotnet Windows forms might be a good alternative for these specific kinds of jobs, so far it doesn't seem so. My impression thus far is it's great for quick and dirty jobs, but not complex ones. What do you guys think? Better to stay with Access and SQL Server or not? Peter |
#4
|
|||
|
|||
dotnet windows forms vs. Access
"PMK" wrote in message ... On Sun, 3 Jun 2007 07:40:33 +0100, "Baz" wrote: I didn't say only, and it's just a first impression - that is one of the reasons I was asking for other opinions, but it is because you can drag and drop so easily, including data connections - makes it easy to knock off a simple application especially using datagrid type controls, yet I am finding it unwieldy to deal with those very same data controls - datasets, etc., manually. Hang on, you want to use unbound forms and yet you are trying to use data-bound controls? Sounds like a contradiction to me. Data-bound controls in Windows forms are indeed clumsy and cumbersome compared to Access, and if that's what you want stick to Access. The datagrid is absolutely hopeless when you compare it to what you can do in Access using linked subforms and continuous forms. What don't _you_ like about VB.net and VS? It's a pig to learn. MS appears to have taken every concept in OO programming known to mankind, and then some more that no-one had ever heard of, and shoehorned them all into dotnet. It's an over-complex, overblown smorgasbord of stuff that no-one needs. I hate the colossal dotnet framework. And I hate the fact that MS killed off "classic" VB, the world's most popular programming environment, in the face of fierce opposition from hundreds of thousands of programmers. I saw your comment about that elsewhere. I don't know why you feel that bound forms is such a huge benefit of Access, but anyway, I use unbound a lot primarily because I find it makes validation so much easier and avoids the complexities of undoing an edit or reversing the addition of a new record, particularly in a sub form. Maybe you saw my comment about it elsewhere because you cross-posted! Bound forms (and reports) are the ONLY benefit of Access. In particular, Access' two most wonderful features are linked subforms and continuous forms, both of which go out of the window when you use unbound forms. This is NOT a criticism of Access, on the contrary, I would rarely use anything but Access for database applications because nothing else even comes close to it. However, if I wanted to build something that consisted of all or mostly unbound forms then I would even use VB.Net in preference to Access. In order to achieve it's wonderful bound-forms capabilities Access comes with all sorts of overheads, and if you don't want bound forms then you don't need the overheads, as simple as that. If you want an analogy, building lots of unbound forms in Access is like buying a 4x4 (or an SUV, if you prefer) and never taking it out of the city. It works, but at a cost which you don't need to incur. How do unbound forms make validation easier? In a bound form you just stick all your validation in the form's BeforeUpdate event procedure and you're done. Undoing an edit? Press the Esc key (or click Undo on the menu). Reversing the addition of a new record? Delete it. How else would you do it? If you add a record through a bound form or an unbound form you still need to delete it if it's a mistake. With a bound form you can do these things without having to write a line of code, with unbound forms you have to program all of these functions. How is that easier? You are using unbound subforms? How, exactly? |
#5
|
|||
|
|||
dotnet windows forms vs. Access
I have done a lot of Access clients to SQL Server and find it very powerful.
Here are some pros and cons: Vs.net provides a lot more functionality for windows clients than access. Therefore it is also more complicated to learn and use. If you do not need the extra functionality compared access, then access could be your choice. My experience is that Access takes a lot less programming effort (in manhours) compared to vs.net to implement the same functionality. I find this to be the big advantage of access. Some of the wizards in access are quite powerful and will require a lot of manual coding in vs.net, especially if you dont have a big library of vs. classes that you can reuse. Access .adp client works fine when the client and the server are within the same intranet. Vs.net provides the possibility to make powerful windows clients communicating with sql server over the internet. If you are familiar with access you can reuse a lot of your knowledge in making access clients to sql server. An access project (.adp file) is usually connected to the SQL Server at all times while it is open. Each connection cause some load on the server. I have never tried thousands of .adp clients connected to the same sql server, but finally the load from idle connections could cause a problem. Vs.net provides a wider set of mechanisms to tune the load on the server (Disconnect when the connection is not needed) and provide better solutions for large number of users. Access usually requires the user to have an valid access user licence (Office etc) and each client therefore has some cost. VS.net clients are free once they are developed. Unbound data entry forms is no problem with access. It requires some coding in VBA, and it is not difficult to learn. Regards Tore "PMK" wrote in message ... I just wonder if I am wasting my time learning VS 2005. I've developed in Access for a long time, and seek out advanced work which invariably requires complex unbound data entry forms connected to a MS SQL back end. Taking a hard look and experimenting with dotnet 2.0 and Visual Studio 2005 to see if dotnet Windows forms might be a good alternative for these specific kinds of jobs, so far it doesn't seem so. My impression thus far is it's great for quick and dirty jobs, but not complex ones. What do you guys think? Better to stay with Access and SQL Server or not? Peter |
#6
|
|||
|
|||
dotnet windows forms vs. Access
On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
Maybe you saw my comment about it elsewhere because you cross-posted! Comments on the topic at hand later, but I think in this case cross- posting was warranted, as I wanted input from different groups of users: Access and .net, most of whom probably don't read both groups. Cross-posting, as opposed to multi-posting, is not inherently evil in my book. However, I'm not going to drag this out - that's my only comment I'm going to (cross)-post. ;-) And the comment I saw about bound forms being a major advantage of Access - I think it was yours - , was in a thread a few weeks ago but I just came across. Peter |
#7
|
|||
|
|||
dotnet windows forms vs. Access
On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
wrote: Hang on, you want to use unbound forms and yet you are trying to use data-bound controls? Sounds like a contradiction to me. Data-bound I can see why. However, I was/am looking at alternatives to the way I have been doing things. controls in Windows forms are indeed clumsy and cumbersome compared to Access, and if that's what you want stick to Access. The datagrid is absolutely hopeless when you compare it to what you can do in Access using linked subforms and continuous forms. Bound forms (and reports) are the ONLY benefit of Access. In particular, Access' two most wonderful features are linked subforms and continuous forms, both of which go out of the window when you use unbound forms. This is NOT a criticism of Access, on the contrary, I would rarely use anything but Access for database applications because nothing else even comes close to it. However, if I wanted to build something that consisted of all or mostly unbound forms then I would even use VB.Net in preference to Access. In order to achieve it's wonderful bound-forms capabilities Access comes with all sorts of overheads, and if you don't want bound forms then you don't need the overheads, as simple as that. If you want an analogy, building lots of unbound forms in Access is like buying a 4x4 (or an SUV, if you prefer) and never taking it out of the city. It works, but at a cost which you don't need to incur. How do unbound forms make validation easier? In a bound form you just stick all your validation in the form's BeforeUpdate event procedure and you're done. Undoing an edit? Press the Esc key (or click Undo on the menu). Reversing the addition of a new record? Delete it. How else would you do That won't work with subforms, and with multiple subforms the coding to deal with all the various errors a user could make in any of multiple fields which will cause the record to save is extremely difficult, time consuming and gives a less satisfying result than unbound forms. I do admit to a fondness for unbound forms in general, as I have found it is easier to create idiot proof forms that way. it? If you add a record through a bound form or an unbound form you still need to delete it if it's a mistake. With a bound form you can do these things without having to write a line of code, with unbound forms you have to program all of these functions. How is that easier? You are using unbound subforms? How, exactly? In Access, local temporary tables. With ADP it can get tricky. Sometimes SQL temp tables, sometimes permanent tables that simply hold the subform info on a temporary basis until it gets saved, or a combination of both. I appreciate your other comments and thoughts. Peter |
#8
|
|||
|
|||
dotnet windows forms vs. Access
On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" wrote:
I have done a lot of Access clients to SQL Server and find it very powerful. Here are some pros and cons: Vs.net provides a lot more functionality for windows clients than access. Therefore it is also more complicated to learn and use. If you do not need the extra functionality compared access, then access could be your choice. Tore, Can you give me a few examples? Peter |
#9
|
|||
|
|||
dotnet windows forms vs. Access
If the topics/examples are limited in database applications, here mentions a
few in general: - All sorts of web applications. MS Access app (*.mdb/*.accdb/*.adp) is typical desktop client application. You cannot create web application with it, either client side or server side. Do not mention Access DAP, it is useless. - Server/Client application(web app or win form app). .NET provide complete set of infrastructure for server side development and client side development (web client, win form, mobile device), which is used by VS (VB.NET or C#), whilw Access is only client side desktop IDE/app. - Even limited on Win form desktop app, with .NET you can easily develop desktop app that uses all sorts of resources on the network (intranet and the Internet) via Web Services/Remoting/WCF. - Multiple tier enterprise system development... As a development tool, VS is a lot richer that Access, as whole. However, there is situation, your unique situation, where Access is the most suitable tool to use. To make correct choice of development tool between VS and Access, one need to know both Access and .NET (note, I say .NET, rather than VS) well. "PMK" wrote in message news On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" wrote: I have done a lot of Access clients to SQL Server and find it very powerful. Here are some pros and cons: Vs.net provides a lot more functionality for windows clients than access. Therefore it is also more complicated to learn and use. If you do not need the extra functionality compared access, then access could be your choice. Tore, Can you give me a few examples? Peter |
#10
|
|||
|
|||
dotnet windows forms vs. Access
I've relied on Access supercharged with VB data marshalling since 1999.
Incredibly fast development, outstanding network performance (125 times standard Access) coupled with 100% reliability. Three years ago, I started transitioning to .NET. A lot of study and experimentation has resulted in fast development, great performance and 100% reliability. The end product looks better and is far more flexible. You can do things in .NET that you can't do in MS Access using multi-threading. Plus, with the extensive framework library, you have more to work with for complex tasks. There are some downsides. Plan on a long learning curve. VS 2005 is a real performance pig (compared to VS 2003). Support from Microsoft is mediocre - the little guys really try harder. All that aside, I'm happy with the outcome and will not go back to Access. An interesting comparison would be between .NET and Delphi 2007 for Win32. I suspect the later might be a better choice. |
Thread Tools | |
Display Modes | |
|
|