.NET Windows Forms Application VS MS Access client Application

dotnet framework

    Sponsored Links

    Next

  • 1. Accessing Selected DataRow from DataGrid
    I'm having difficulty with identifying the selected DataRow in my DataGrid. Here is the situation: I have a DataSet with several tables and relationships between the tables. This situation concerns a parent child table pair. I created a DataView for my parent table. The child table is related with a ParentToChild relationship. I defined two DataGridTableStyles, one each for the parent and child tables and added them to the DataGrid.TableStyles. The user selects a Parent row from the DataGrid DataView and then I use the DataGrid.NavigateTo(myHitTest.Row, "ParentToChild") method to show the related Child table rows. They are displayed as defined by the associated DataGridTableStyles. Everything works find to this point. Now, however, the user selects a row from the DataGrid and I need to know the child table row that has been selected. Ie tried several approaches but with no success. Here is my latest attempt: int intRow = 0; foreach( DataRowView drv in myDataView ) if( myDataGrid.IsSelected(intRow++) ) OpenEntry( (int)drv.Row["entry_id"] ); The problem I have is that myDataView still returns the Parent table rows and myDataGrid still refers to the Parent table as well (i.e. the selected row is the one selected in the Parent table not the Child table rows currently displayed). How do I get at the data behind the displayed view?
  • 2. Form resize not working correctly after upgrading to Framework 1.1
    Hi all, I Generic form contains two panels. The lower panel (with fixed height) contains buttons, the upper panel is empty but set to fill the rest of the form space. In this form I have a function to set any User control I want in the upper panel. Then it resizes the form accordingly to see the entire user control and the lower button panel. Here is the function: public void SetControl( Control ctrl ) { _upperPanel.Controls.Add( ctrl ); // Size the window according to the new panel int deltaW = ctrl.Width - _upperPanel.Size.Width; int deltaH = ctrl.Height - _upperPanel.Size.Height; this.Size = new Size( this.Size.Width + deltaW, this.Size.Height + deltaH ); } This was working perfectly with .NET 1.0. However I noticed that after upgrading to .NET 1.1, the height of the form was not working anymore. It was missing a little. What is weird is that the width is resizing correctly. And if I copy the resizing code above (3 last lines) twice in the same function it works. Any ideas? Thanks, Hugo
  • 3. Get a reference to windows directory ?
    There is no enumeration for the windows directory in SpecialDirectories, how can I get the windows directory path ?
  • 4. Propertygrid eating keystrokes
    I have a very simple form with a menu where the top level items are &file and e&xtras. Normally you can type Alt-F to display the file menu. Now I have added a propertygrid to the form using this code: declarations section: private withevents pg as propertygrid Form_Load: pg = New PropertyGrid() pg.SelectedObject = Nothing pg.Dock = DockStyle.Fill panProp.Controls.Add(pg) where panProp is a panel on the form. Now I can't type Alt-F anymore on the form. Really annoying. I have to type Alt, release it and then type F. Is this a bug in Propertygrid? If yes how can this be solved? It works until the property grid is added. Tosch
  • 5. Drawing toolbox ?
    I can't find a drawing toolbox in windows forms - how can I draw lines, squares, circles etc on my form surface ?

.NET Windows Forms Application VS MS Access client Application

Postby Jordan S. » Fri, 14 Apr 2006 08:09:39 GMT

QL Server will be used as the back-end database to a non trivial client
application.

In question is the choice of client application:

I need to be able to speak intelligently about when one client (MS Access vs
.NET Windows Forms) would be preferred over the other. While I have some
good arguments on both sides, I would appreciate your points of view on the
topic.

For the sake of this discussion, please assume a *non trivial* client
application with, say 120 forms, secure data processing, hundreds of
reports, and a clear need for a rich UI experience (MDI, a variety of rich
UI controls, non trivial printing requirements, etc).

I would appreciate help in compiling arguments both for and against each
technology (MS Access and .NET Windows Forms) as a client application.

So far I have this (in no particular order):

BENEFITS OF a .NET Windows Forms Application:
1. Client can be MDI (whereas Access only SDI)
2. Much richer UI with .NET (vs MS Access UI controls)
3. Easier deployment (with ClickOnce, XCopy, and similar .NET technologies
or methods). The client already has the CLR installed as part of their
standard desktop image - so I need to put nothing more than "XCopy" the
application files onto the local machine.
4. .NET requires a smaller footprint on the client with respect to the use
of 3rd party UI controls. MS Access is a COM-based technology and therefore
requires that 3rd party controls be COM controls. These require installation
to Windows\System32 and associated updates to the Registry (whereas .NET 3rd
party controls require only XCopy deployment to the application folder)
5. 3rd party UI controls for .NET are more prevalent, capable, and rich than
3rd party COM controls. Plus support for COM controls (i.e. number of 3rd
party companies making and supporting them) is expected to only decrease,
not increase, during the coming years - with the exact opposite trend
expected for 3rd party .NET controls.
6. .NET Windows Forms applications can take full advantage of OOP constructs
and patterns - thereby enabling the developers to create applications that
are easier to maintain, more easily extensible, and better architected than
the "equivalent" functionality provided in an MS Access application.
7. Visual Studio .NET significantly increases developer productivity (vs MS
Access support for application development)
8. The .NET base classes significantly increase developer productivity by
pre-packing substantial functionality that would have to be coded from
scratch in MS Access.
9. Runtime performance of a .NET application would likely be faster than MS
Access because MS Access (really Jet) necessarily entails a file server
architecture, while ADO.NET necessarily entails a distributed (and
disconnected) architecture.
10. ADO.NET takes care of connection pooling automatically and provides a
huge amount of built-in functionality that substantially increases developer
productivity and increases programmer control over database communications
and updates (as compared to JET and DAO).

DOWNSIDE OF a .NET Windows Forms Application:
1. Increased expertise required for .NET development - vs. MS Access (at
least that's the perception of the client)
2. Requires the target version of the CLR to be installed on the client
machines (leading possibly to multiple versions of the .NET Framework
installed simultaneously. Not that I have a problem with i

Re: .NET Windows Forms Application VS MS Access client Application

Postby david epsom dot com dot au » Fri, 14 Apr 2006 11:08:37 GMT

hat's amusing. I won't attempt to correct your opinions,
but note that you haven't addressed reporting yet. I've
used Crystal, Access, and Report Services, and my opinion
is that you really need to accommodate the skill set of your
developers.

(david)



"Jordan S." < XXXX@XXXXX.COM > wrote in message
news:% XXXX@XXXXX.COM ...



Re: .NET Windows Forms Application VS MS Access client Application

Postby Jordan S. » Fri, 14 Apr 2006 11:50:52 GMT

Thanks for your perspective. Skill set of the developers is very important 
as you mentioned, and a shorter learning curve on Access may be relevant to 
the final decision.

Please feel free to add to the lists - *all* sides must be represented.





Re: .NET Windows Forms Application VS MS Access client Application

Postby TC » Fri, 14 Apr 2006 17:42:57 GMT

Why do you say that Access is only SDI? You can open multiple forms,
each one individually resizable & repositionable within the Access
application window. Sounds like MDI, to me!

One of the primary advantages of Access, IMO, is its data-bound
controls. You don't need any code at all, to bind a control to a field
in the data source of a form or report.

As for the rest, IMHO you are asking too much from a newsgroup staffed
by volunteers. It would be a non-trivial consulting task to provide the
detailed comparative report that you want. And you'd really want it to
be done by someone who was expert in both technologies (winforms and
Access). Otherwise, it's too easy for the winforms person to slag
Access (through lack of knowledge of the product), and vice versa.

HTH,
TC (MVP Access)
 http://www.**--****.com/ 


Re: .NET Windows Forms Application VS MS Access client Application

Postby Will » Fri, 14 Apr 2006 17:47:56 GMT

It just frightens me that anyone would even consider using MS Access as
anything other than a torture device. Your point #6 for .NET benefits
is very important, and could easily be split out into about 20.

When the application needs to change to do some extra functionality
like access a web service, or perform complex operations on your data
then you would start crying if you were using access. An application
with 120 forms is probably going to have some seriously complex
requirement changes coming out that you won't find out about until mid
way through developing it (usually when the client actually sees a
screen working then says "oh, but if it's a saturday and it's raining
we don't do it like that"). You'll need the ability to put in some
serious design patterns that permit you to change this without having
to re-structure everything.


Re: .NET Windows Forms Application VS MS Access client Application

Postby TC » Fri, 14 Apr 2006 18:06:27 GMT

Nonsense. A well designed & written systems can generally be enhanced
without much trouble. A badly designed & written system can't. The
workman has much more effect on this, than the tool. You could easily
have a well designed & written Access system, that was easy to enhance,
and a badly designed & written .NET system, that was a nightmare to
enhance.

TC (MVP Access)
 http://www.**--****.com/ 


Re: .NET Windows Forms Application VS MS Access client Application

Postby Brendan Reynolds » Fri, 14 Apr 2006 18:38:24 GMT

"Jordan S." < XXXX@XXXXX.COM > wrote in message
news:% XXXX@XXXXX.COM ...


While it is true that there is a wider range of controls available in .NET,
Access provides all the controls that a typical data-centric application
really needs.


See my answer to point 2 above. The availability or otherwise of third-party
controls isn't an issue when you don't need any third-party controls.


See answers to 2 and 4 above.


This has not been my experience.


This has not been my experience.


I can't say for sure whether a .NET app is likely to be faster, but I can
say from experience that a well-designed Access app can perform more than
satisfactorily on a LAN.


See answers to 7 and 8 above regarding developer productivity.


Not necesarily. Access 2002 and 2003 use the same file format by default as
Access 2000. You can run the same MDB under the last three versions of
Access, provided you are careful not to use any new features that were not
supported in Access 2000.


You haven't mentioned what you're going to use for reporting in .NET. SQL
Server Reporting Services is cool in many respects, but I miss the tight
integration of the Access report designer and engine, and SQL Server
Reporting Services requires additional installation and configuration on the
server.

Generally speaking, my experience so far is that ASP.NET has been a great
leap forward for Web-based applications, but I remain to be convinced about
the benefits of using Windows Forms for typical data-centric desktop
applications.

--
Brendan Reynolds
Access MVP



Re: .NET Windows Forms Application VS MS Access client Application

Postby Will » Fri, 14 Apr 2006 18:43:14 GMT

Fair point that the developer skill is the key factor.

But do you really see Access as a scalable solution for a 120 form
application? I do admit that I've only had a few frustrating encounters
with access forms applications, however it seemed to me that while
their databound controls are their strength for a simple application,
they lack the expressiveness available to .NET controls. I can see the
advantage of access forms if it's managing the database as well, but
when you need to have very particular formatting of your controls, and
tie in to a large variety of events .NET is definitely easier / more
obvious in how to do this.

Secondly, while I do accept that a .NET application can be written
badly, if written well then it will provide a more scalable and
maintainable architecture. I don't believe that Access was designed to
develop complicated middle tier logic, and while it may be possible to
do it in Access, .NET was built with this in mind.

I do agree we shouldn't start bashing other technologies though, so
please ignore my "torture device" comment posted previously


Re: .NET Windows Forms Application VS MS Access client Application

Postby TC » Fri, 14 Apr 2006 19:16:39 GMT







Access can easily handle 120 forms. There'd be squintillions of working
Access databases around the world with that number. However, you're
certainly right, that the number can not grow arbitrarily. So, winforms
might be more scalable here - I don't know.

But it does raise the question, how many is enough? What are all these
forms *for*, in systems that have hundreds & hundreds & hundreds of
forms? Every time I hear of one, I think: "Geez, surely it would be
possible to have a smaller # of forms & let them customize themselves
at runtime".



It's hard to comment without specifics. You may be right - I don't know
enough about winforms to have an opinion. Certainly the Access event
model has a few deficiencies.



You may well be right. I don't know enough about .NET & winforms to
have an opinion yet.



No probs, thanks for that acknowledgement. I was girding my loins, to
enter the fray!

Cheers,
TC (MVP Access)
 http://www.**--****.com/ 


Re: .NET Windows Forms Application VS MS Access client Application

Postby Jordan S. » Sat, 15 Apr 2006 00:24:46 GMT

Thanks for your perspective TC.

A couple of thoughts:
RE:
<< It would be a non-trivial consulting task to provide the detailed 
comparative report that you want.>>
Exactly! That's my job and that's why I provided the initial lists in the OP 
(to get the ball rolling). I hope I provided at least the "big hits" and 
that that good folks here in the NG can just scan and say "oh, you missed x, 
y, or z".

RE:
<< And you'd really want it to be done by someone who was expert in both 
technologies (winforms and Access). >>
That's me to some extent also. FWIW I have 5 years of full-time and non 
trivial MS Access programming experience (Access 2.0 through 97), 4 years in 
VB, and 3 in .NET. So I can lay claim to some awareness of the strengths of 
MS Access, plus some other technologies.

RE:
<< Otherwise, it's too easy for the winforms person to slag Access.... and 
vice versa >>
I'm not here to bash MS Access nor start any flame war. I'm just recognizing 
a situation where it may not be the *best* tool for the job. Rather than 
just saying "geeze we shouldn't use Access for non trivial UI programming" I 
want to be able to state specifically why. And if I'm wrong in my 
assumptions or beliefs then I also want to know specifically why.

Finally, towards avoiding a flame war, I'd like to encourage respondents to 
avoid arguing against any points anyone here makes. All are taken as either 
[completely valid] or [perceived as valid] and thus are greatly appreciated.

Thanks again! 



Re: .NET Windows Forms Application VS MS Access client Application

Postby SP » Sat, 15 Apr 2006 01:05:14 GMT





Without knowing the requirements I have the following comments.

You mentioned Jet a few times although you said the backend was to be SQL 
Server. I would find out how or if Jet is even involved in a MS Access 
application connecting to a SQL backend.

I have done some MS Access applications in the past. Primarily these were 
data entry applications with reporting requirements. The editable controls 
on the data entry screens had a 1 to 1 relationship with a table. The client 
in these cases was looking for a way of getting information in so they could 
get information out.

The requirements may not lend themselves to a purely data-centric 
application but to an application based on an object model. How much 
business logic is involved? Are there computational requirements involved as 
the data is entered? What is the client's most sophisticated requirement?

SP






Re: .NET Windows Forms Application VS MS Access client Application

Postby Jordan S. » Sat, 15 Apr 2006 01:34:36 GMT

Thanks for jumping in SP.

RE:
<< What is the client's most sophisticated requirement?>>

They are, in no particular order:

- Fast performance on a busy LAN/WAN (*very* important to the client)

- Maintainability (ease of modifying existing features; and "no touch" and 
automatic installation of client application updates)

- Extensibility (ease of *quickly* adding substantial new functionality)

- Web access (eventually wants a Web UI in addition to Windows Forms UI)

- MDI (with floating/dockable toolbars and windows, etc)

- Intuitive and attractive UI controls - including grids that can host 
embedded controls (like a pop-up calendar or combo box).

- Multiple "security levels" (UI controls or entire forms are 
enabled/disabled/hidden depending on user's security access level)

- Interfacing with external systems (as either a TCP client, as the consumer 
of a Web service, and sending e-mail).

- Non trivial printing requirements; beyond simple reports.

Since it's been mentioned a couple of times in the thread, yes - MS Access 
has a great report writer - built right in. For a .NET Windows Forms 
application I'd tend to go with ActiveReports from DataDynamics 
( http://www.**--****.com/ ). 
It lets one bind a report to a variety of in-memory structures (lists, 
arrays, etc) in addition to ADO.NET DataSets and DataTables; it's also 
programmable with the hosting .NET language (e.g., C# or VB.NET), so no need 
to learn some proprietary scripting language as is the case with Crystal.


-Jordan S. 



Re: .NET Windows Forms Application VS MS Access client Application

Postby SP » Sat, 15 Apr 2006 02:09:34 GMT






Based on these requirement I would definitely be looking at .Net and not 
Access. It seems way beyond a "data entry" application.

SP 



Re: .NET Windows Forms Application VS MS Access client Application

Postby david » Sun, 16 Apr 2006 16:36:23 GMT

> But do you really see Access as a scalable solution for a 120 form

Yes, we have way more than 120 forms in our application. I admit that when
we built our own template form and control objects, they were less robust,
harder to maintain, and had fewer features than the form and control objects
provided by Access, but perhaps most development shops really are better
than MS at creating form and control object templates.

The 'middle tier' argument is less often argued. In our case, we do have a
'middle tier', but it is a client-side middle tier, which limits
scalability, and only accessible from Access, which limits our options. I
can think of few situations in which I would decide, ex nova, to create a
middle tier in Access.

(david)








Re: .NET Windows Forms Application VS MS Access client Application

Postby TC » Sun, 16 Apr 2006 18:46:54 GMT

i Jordan

One more pass from me. Note that I am *not* saying that in my opinion,
Access would be suitable for your client's application. I'm just
responding to some of the points in your original post.




Access is MDI by default. See my earlier post in this thread.



But - like what? You mentioned calendars. But calendars are easy to
program as a "drop in" Access popup form; and the next version of
Access might have some surprises here! So IMHO, you'd need to support
the allegation of "richer UI" by naming some specific types of controls
that .NET has, and Access doesn't.



As above: Why? Who says?



Truly, the developer is 90% of the equation & the toolset is 10% - if
that. If you don't believe me, just read the regular abominations on
http://www.thedailywtf.com - most of which are written in modern
toolsets like .NET! Some of the modern examples are completely
unmaintainable. A modern platform will not enforce maintainabilty *or*
enhancability. You're off-course if you're hoping that. Skilled
developers will produce maitainable & enhanceable systems, even on a
suboptimal platform. Unskilled developers will produce pea soup - even
on the very best platform. Management, of course, asume that the
"latest & greatest" toolset will solve their software development
problems. But that is just a hopeful assumption, in the absense of hard
statistics & studies.



Who says? For what kinds of developers? Where is the evidence? You may
well be right - but I'm just saying, you can not argue by assertion.
You have to have some evidence. It sounds to me like: "It's newer -
thus better!"



Again - Like what? Who says? It's a "warm & fuzzy" statement that
proponents of .NET will undoubtedly agree with. But how do you know it
is true? How do you plan to *measure* your developer's productivity?
How will you *know* how productive (or not productive) they are? Is the
client *already* measuring dveloper productivity? If not, how will they
*know* if it increases - or decreases?



You're proposing a speed advantage for client server over file server.
Fine - but Access has no preference between the two, so the comparison
is nothing to do with Access as such.


Finally, I should stress again that I am *not* saying that in my
opinion, Access would be suitable for your client's application. I'm
just responding to some of the points in your original post. I feel, in
summary, that some of them are long on assertion, and short on actual
evidence!

Cheers,
TC (MVP Access)
http://tc2.atspace.com


Similar Threads:

1.ASP.NET vs Windows Forms for building client application

I kind of understand the ASP.NET architecture in terms of building web pages 
with embedded server controls, where the .aspx is run on the client and the 
.aspx.cs runs on the server.

But what if I want to build an ASP.NET based application that is to be run 
entirely on a client (all files hosted on the client and run on the same 
client)? What would that client need to run it?

I want to write an application that can be run standalone on a PC (not 
hosted on a web server and accessed from a PC), which uses web technology 
like javascript and Ajax, while also being able to code the primary logic in 
C#. I have the choice of a windows forms rich client application which uses 
a WebBrowser control, or a native ASP.NET application. But I'm not sure the 
latter is even feasible for being deployed and run standalone on a PC - 
would it need IIS and .NET framework installed, and even more? 


2.Converting MS Access 2000 application to a VB / VB.NET application

Hello All

I am trying to convert a MS Access 2000 application to a VB application
(Just Started Yesterday)

I am using Visual Studio .NET 2003 utilizing Visual Basic .NET

I think I have a good feel to what I have to do, but does anyone know of a 
GOOD white paper on what is involved, pitfalls, etc?

So far I have run into one problem that I have not been able to figure away 
around.
That is how to access the tables.  In access you have Database objects, 
Recordset objects and all if the associated methods.  I cant seem to find out 
how to convert this to VB.  I have been reading through postings in this 
Discussion Group, but I am still a little bit confused.

Is there a SIMPLE way to access the existing .MDB database tables, and the 
individual fields within the tables.  Any help would be greatly appreciated, 
or a pointer to a good white paper describing the procedure.

Thanks in advance     

-- 
George H. Slamowitz
(602) 765-8111
(602) 765-8222 (FAX)

3.Connection to remote COM object works in Windows Forms application but not in ASP.NET application

Hello there,

The following code causes "Specified cast is not valid" exception when line
3
executes inside an ASP.NET application. I have tried this with several
components. Exactly the same code works if
connecting locally (i.e with localhost) and it always works from a Windows
Forms application even if connecting to another computer.

Here is the code:

Type type = Type.GetTypeFromProgID("CorporaServer.CorporaAppServer",
"RemoteServer");
Object objTest = Activator.CreateInstance(type);
CorporaAppServer CorporaServerObj = (CorporaAppServer)objTest;  // exception
"Specified cast is not valid" raised here

Anybody knows why this could happen? Thanks in advance,

Jose R. Rodruez




4.Send information from a Visual FoxPro application to a VB.Net Windows forms application

Hello,
    I am working on an application in VB.net.  The application is
actually replacing a tab in a FoxPro application.  When the tab is
activated in the Foxpro application, it runs my VB.net app with the
current information that has been selected.  The users like to go back
and forth between the vb.net application and the Foxpro app.  Every
time they click on the tab it starts a new instance of my application
so they are having the issue of multiple instances of the vb.net app.
Is there a way to send a string to a vb.net app that is already
running?  I know there are interops to call vfp from vb.net but I need
to go the other way.

Any help is appreciated 
thanks

5.Connection to remote COM object works in Windows Forms application but not in ASP.NET application

Hello there,

The following code causes "Specified cast is not valid" exception when line
3
executes inside an ASP.NET application. I have tried this with several
components. Exactly the same code works if
connecting locally (i.e with localhost) and it always works from a Windows
Forms application even if connecting to another computer.

Here is the code:

Type type = Type.GetTypeFromProgID("CorporaServer.CorporaAppServer",
"RemoteServer");
Object objTest = Activator.CreateInstance(type);
CorporaAppServer CorporaServerObj = (CorporaAppServer)objTest;  // exception
"Specified cast is not valid" raised here

Anybody knows why this could happen? Thanks in advance,

Jose R. Rodruez




Return to dotnet framework

 

Who is online

Users browsing this forum: No registered users and 54 guest