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 |
#11
|
|||
|
|||
dotnet windows forms vs. Access
Per Baz:
Hang on, you want to use unbound forms and yet you are trying to use data-bound controls? Sounds like a contradiction to me. I use a third approach: forms bound to temp tables on C:. -- PeteCresswell |
#12
|
|||
|
|||
dotnet windows forms vs. Access
The datagrid is
absolutely hopeless when you compare it to what you can do in Access using linked subforms and continuous forms. Can you please join some of the VB groups and make this argument...please? g I've tried to on a couple of occasions (one of the larger debates was just a week or two ago)...nobody seems to believe/understand me, and were telling me how "unprofessional" Access apps look compared to VB apps. Personally, I've yet to see anything in any version of VB that comes close to the flexibility of Access' subform and continuous form capabilities. Rob |
#13
|
|||
|
|||
dotnet windows forms vs. Access
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 believe you can also use subforms using ADO recordsets bound to the ..Recordset property...but I do seem to remember a lot of crashiness and other problems going that route, so I don't recommend it, necessarily. Rob |
#14
|
|||
|
|||
dotnet windows forms vs. Access
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. The one exception to this is that if you have the Office Developer's edition, you can re-distribute the Access runtime freely, so this may not be a problem. Rob |
#15
|
|||
|
|||
dotnet windows forms vs. Access
- 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. While it's far from complete, Access can provide server-side development for SQL 2000 (or SQL 2005, if you're using Access 2007, I gather). - Multiple tier enterprise system development... No reason you can't do this in Access as well, though you'd need help from some other development platform to create the middle tiers, most likely. (Conceivably, you might be able to do it entirely in Access, but why you'd want to is beyond me.) Rob |
#16
|
|||
|
|||
dotnet windows forms vs. Access
Per Jim Rand:
Three years ago, I started transitioning to .NET. A lot of study and experimentation has resulted in fast development A few years back I was flirting with .NET. But then I asked myself "What do I deliver to my clients that makes me different from 10,000 highly-skilled, really-smart, energetic people in Bangalore?" I came up with three things: ------------------------------------------------------------ 1) Really-RAD Development. I can turn on a dime and deliver faster than any IT shop - anywhere. My experience developing the same app in VB6 vs MS Access led me to think that VB took three times the man hours. Others have opined 5 or 6. I don't see this as a dollar thing - because an offshore shop might bill ten times the hours, but at only a twentieth of the rate..... but it relates to the "turn on a dime" and short delivery time aspects. 2) Minimal User Impact: The people I serve tend to be in highly-competitive positions where they're already being stretched to the max. They live and die by numbers and if they falter, they're history. Working with IT means they have to devote significant man hours to filling out specs and meeting with programmer/ analysts - as opposed to just saying "Hey Pete.. how about..." ------------------------------------------------------------- Questions - now that you're up to speed with .NET: ------------------------------------------------------------- 1) Do you feel that you can make midstream changes in .NET as quickly as you could using MS Access? 2) What do you think your own ratio of MS Access man hours to VB.NET man hours on the same application would be? ------------------------------------------------------------- -- PeteCresswell |
#17
|
|||
|
|||
dotnet windows forms vs. Access
I came up with three things:
1) Really-RAD Development. I can turn on a dime and deliver 2) Minimal User Impact: The people I serve tend to be in Uh...what happened to 3) ? |
#18
|
|||
|
|||
dotnet windows forms vs. Access
Per Robert Morley:
I came up with three things: 1) Really-RAD Development. I can turn on a dime and deliver 2) Minimal User Impact: The people I serve tend to be in Uh...what happened to 3) ? RCI. Mea Culpa. -- PeteCresswell |
#19
|
|||
|
|||
dotnet windows forms vs. Access
Per (PeteCresswell):
Uh...what happened to 3) ? RCI. Mea Culpa. To clarify..... At first I had thought that my customers valued the lower cost of minimal man hours - making the third item. But as I wrote the post, I realized that I've come around to believing that the lower cost isn't such a big thing with most of them. Some of the hospitals, maybe... but the hardcore financial/bond trader types that I serve 95% of the time, no. In those cases I'm a miniscule slice out of a very large pie. -- PeteCresswell |
#20
|
|||
|
|||
dotnet windows forms vs. Access
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. Well, for un-bound forms, ms-access is the wrong tool. If you use un-bound forms in ms-access, you get the WORST of both worlds. VB and vb.net has tons of wizards and some nice data "binding" connection controls that really go a long way to helping you build forms in vb.net. In ms-access, the whole system is built around bound forms. So, the books, the tweaking, the training, code examples, and yes even the wizards are all built around a bound forms model. Further, the form has 2 or maybe 3 times the number of events as compared to vb forms. We have before update, after update, on insert.... the list is HUGE compared to vb forms. and, we even have two events for when the form loads on-open - this event can be used to cancel the form load (a huge missing feature in vb) on-load - allows you to run setup code for the form... So, environments like vb.net are DESIGNED around a un-bound forms mode, and have HUGE number of wizards and features to deal with type of environment. With access, we have a bound forms object model, and if you give that up, you have no special wizards, no special tools, and simply are moving right out of the environment of which ms-access was designed around. You get the worst of both. Several here have stated that once you go the un-bound road, then ms-access is just not the tool. You *can* do this in ms-access, but IMHO, it just not worth it. If you go un-bound forms, then vb.net going to run circles around ms-access. However, with bound forms...we still kick vb.net butt in terms of building data edit forms. I freely admit there is a tipping point in with the user interface you need is better done in vb.net. However, for *most* business line applications I write...ms-access is still the first choice..by a long shot... You going to have to give some examples as to why you found vb.net not you cup of tea.... -- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada |
Thread Tools | |
Display Modes | |
|
|