.NET Windows Forms Application VS MS Access client Application

dotnet framework

    Next

  • 1. Hiding the selection in a CheckedListBox
    Is it possible to do away with the "selected" appearance of an item in a CheckedListBox (v1.1)? When I click an item, its background turns blue and its text turns white. I want the checkbox to toggle (which it currently does), but I don't want the list item to appear "selected". TIA Jared
  • 2. Verify if a DLL is used in ASP.NET application or Windows application
    Hello I have a managed class library (written in C#) that is used both in ASP.NET and Windows applications. How can I determine which platform has been called a class method in this library. Thanks in advance. Hamed
  • 3. Frustrating problem with DatGridView
    I have a DatagridView bound to a bindingsource. I programmatically add a ComboboxColumn and bind it to another BindingSource like this: Dim colActType As New DataGridViewComboBoxColumn colActType.DataSource = ActivityTypesBindingSource colActType.HeaderText = "Activity Type" colActType.DataPropertyName = "ActivityTypeId" colActType.ValueMember = "Id" colActType.DisplayMember = "Descr" DataGridView1.Columns.Add(colActType) The values behave as expected. The displayed values in the Combobox correctly display the value from the Descr field. Changing the value saves correctly to the main table. The problem is that when the DataGridView displays, the Combobox column displays the value in the ValueMember field. When I click in the combobox, it shows the DisplayMember value, but reverts back when I click or tab away. Any thoughts would be helpful. Barry PS: Apologies if this message posts twice. I'm not sure why that is happening here.
  • 4. Memory Consumption
    HI, there, I am developing the desktop application using VB 6 as well as VB.Net. I have noticed one significant difference. A created an empty windows app in VB contsing of a single form and there is no coding and any control on it. When I executed the EXE, it consumed 983KB of memory. I created the same type of EXE in VB.net and when I executed I was astonished to see that it Consumed approx 15 MB of Memory. I looked very strange to me as from the primary analysis I think it might me that CLR launched all the necessary DLL's in the memory space of the EXE that i created like, System.Windows.dll, System.dll etc. But I just want to know if this is the case then .NET windows applications are very memory consuming as compared to their VB counterparts. Could any one please eloberate this issue to me? -- Sunil Pandita Software Engineer (OTS Solutions Pvt. Ltd. )

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

Postby TC » Sun, 16 Apr 2006 18:57:26 GMT

Further to the "developer versus toolset" thing, tell me what level of
"increased productivity" you would expect from the following developer:

     http://www.**--****.com/ 

Hmm ... negative?  fractional? :-)

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


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

Postby Jordan S. » Mon, 17 Apr 2006 03:31:02 GMT

hanks for jumping back in, TC:

I think you identified a place where I may misunderstand MS Access... so if
you'd be kind enough to please elaborate. Regarding MS Access having a [file
server architecture]: In response to my apparent misunderstanding you wrote
<< Fine - but Access has no preference between the two [file server vs
client server], so the comparison is nothing to do with Access as such >>.
Can you elaborate on how MS Access can take on a true client relationship in
a client/server relstionship with say an MS SQL Server database? I'd
appreciate it.

Clarifying that one fact (above) may cause my final analysis to take a
completely different direction. It has huge implications for performance of
MS Access client applications. I'd hate to inaccurately misrepresent what's
possible and what's not.

Separately, I *completely* AGREE with you that anyone can write bad code in
*any* language or platform.

RE:
<< You may well be right - but I'm just saying, you can not argue by
assertion>>
Correct again!
So here's some objective data, the sort of which you inquire (although it
doesn't directly compare MS Access with .NET, it certainly provides support
for the general assertion that .NET offers increased developer productivity
vs other techologies).
http://www.gotdotnet.com/team/compare/petshop.aspx
http://www.promoteware.com/Module/Article/ArticleView.aspx?id=10

Additionally, subjective analysis cannot be completely discounted (just like
"objective" analyses can never really be truly objective). Nobody's going to
be able to take the time to conduct highly controlled lab experiments and
subsequently replicate them in order to verify results in some big effort
to obtain "objective, quantifiable" measures of some claims. Sometimes we go
on simple, straight-forward, deductive reasoning. So it's not really fair or
reasonable to say that someone must come up with "objective" data to back up
all assertions, and if they don't, then their assertions are automatically
presumed false.

So, here's an example of how one could arrive at a conclusion that .NET
increases developer productivity (by using simple deductive reasoning)
without going to a lab and conducting experiments:
If, in VBA I want an array that is sorted, I have to do the sorting myself
in code that I write. I have to chose a sorting algorithm, then implement
it - which means testing and debugging. That all takes time. On the other
hand, the .NET base classes include a class called ArrayList which can sort
itself. So I have to write one line of code to tell the ArrayList to sort
itself. So, "common sense" (yes - I know it's rather uncommon!) tells us
that it takes less time to write one line of code vs. writing many lines of
code; therefore increased developer productivity. So the claim (that .NET
base classes increase developer productivity) is more than a "warm and
fuzzy" statement. It IS a warm and fuzzy statement, but it's also a TRUE
warm and fuzzy statement :-)

NEXT:
RE:
<< Re"Much richer UI with .NET (vs MS Access UI controls)"...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.>>

Here are a bunch of specific types of controls that .NET has that Access
doesn't (and this is from just one 3rd party control provider):
http://www.infragistics.com/products

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

Postby TC » Mon, 17 Apr 2006 04:38:14 GMT





No probs. I'll just address your first point, and get back to the
others tomorrow. It's now 5 AM here, and I haven't eaten dinner yet!



Here's the gen: Access is not a database engine. It has no inherent
database capabilities. It is entirely unable to create or manage
database tables or indexes, parse & execute SQL statements, control the
access of multiple users, and all the other "database engine" tasks
that are required of it. It simply does not do those tasks.

Instead, Access is just a front-end interactive development environment
(IDE), which lets the user create, manage, store & execute forms &
reports. It *seems* to let the user create & manage tables & indexes,
parse & execute SQL statements, and so on - but it *defers* those tasks
to an external database engine. Without an external database engine,
Access can not do those tasks.

By default, Access comes together with MS Jet, which is a *file server*
database engine. So, when an Access form or report executes an SQL
statement, for example, Access (on the client PC) will:
- parse the statement;
- pull in some index data blocks from the back-end database file on the
server;
- use that index data to work out what further data blocks it requires;
- pull in those further data blocks from the server,
- munge it all together (eg. to action JOINs or UNIONs), then
- extract the actual data columns & rows required by the SQL statement.

But an Access front end can just as easily use a *client server*
database engine such as SQL*Server or Oracle. In that case, the Access
form or report can execute an SQL statement in "pass through" mode; in
which case, Access (on the client PC) will:
- pass that statement to the client/server back-end database;
then the *client/server back-end database* will:
- parse the statement,
- work out how to execute it,
- execute it,
- collect the actual data columns & rows required by the SQL statement,
then
- send that data (and *only* that data) back to the Access front-end.

So as you can see, Access does not say: "I am a file srver database
program". It says: "I am a front-end interactive development
environment. Connect me to whatever back-end database engine you want".

I'm not saying that the same code would work, unchanged, with equal
efficiency, against a file/server back end (eg. MS Jet) *and* a
client/server back end (eg. SQL *Server). You'd need to know the
back-end type, up front, to write the most efficient code. I'm just
saying that Access, *itself*, is agnostic as to the ature (file server
or client/server) of the back-end database engine.

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


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

Postby Tony Toews » Thu, 20 Apr 2006 09:06:27 GMT




How is .Net going to make this kind of restructuring easier?

Tony
-- 
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
 http://www.**--****.com/ 

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

Postby Tony Toews » Thu, 20 Apr 2006 09:08:09 GMT




I had one system with 450 forms and 350 reports.  But I needed them
all.  There were 160 tables in the app.

Tony
-- 
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
 http://www.**--****.com/ 

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

Postby Tony Toews » Thu, 20 Apr 2006 12:41:57 GMT




Once Access, likely runtime for all but your power users who will be
doing their own ad-hoc queries, reporting and exporting to Excel, is
installed, you can use the free Auto FE Updater so the clients can
pull down updates

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version.  For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
 http://www.**--****.com/ 
FE on each PC up to date.

In a Terminal Server or Citrix environment the Auto FE Updater now
supports creating a directory named after the user on a server.  Given
a choice put the FE on the Citrix server to reduce network traffic and
to avoid having to load objects over the network which can be somewhat
sluggish.


That's Access.


But if the number of remote users is relatively small and controlled,
ie employees who are on the road or remote branches you may want to
consider Terminal Server/Citrix.   In that scenario that cost would
likely be cheaper than a lot of work in getting the app to run on a
Web UI.  This is in respect to an Access app.   I have no idea how
quickly a Windows Form UI could be converted to work well on the web.

Now if the potential users are indeed general public using web
browsers then ignore my suggestion in the above paragraph.   Although
even then such users may only require a small subset of the complete
apps functionality.


Well, my users are pretty happy with the standard Access controls.
And using a pop calendar form rather than a control.   Combo box?
With one exception the one in Access is quite good.  The exception
being combo boxes on continuous forms where you want the source to be
different on each row.


A little bit of home grown security combined with SQL Server security
would suffice here.   Along with MDEs and blocking special keys or
whatever the setting is.


Sure.

Tony
-- 
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
 http://www.**--****.com/ 

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

Postby Tony Toews » Thu, 20 Apr 2006 12:44:14 GMT




One person I know quotes a .NET app as taking six times as long to
develop as the equivalent Access app.    He is the technical person
for a largish consulting company in Sydney Australia.



Pretty sweeping statement


No.  If you distribute an A2000 MDE then A2000, A2002 and A2003 can
run the app.  Furthermore you can do the development in A2003 and just
revert to A2000 when creating the MDE.


Code no.   Queries yes.

Tony
-- 
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can 
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips & Accounting Systems at 
 http://www.**--****.com/ 

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

Postby Jordan S. » Thu, 20 Apr 2006 14:21:21 GMT

Thanks for the feedback Tony. Very helpful (throughout the thread today), 
especially for clarifying some incorrect beliefs I held (like MS Access apps 
being Access version-dependent).

Now, a couple of things:
RE: << One person I know quotes a .NET app as taking six times as long to 
develop as the equivalent Access app. >>

That's easily the case when we're dealing with bound controls with little or 
no programming logic (or at least relatively straight-forward programming 
logic). But get into anything non trivial and there's just no way to 
substantiate the cliaim that .NET takes longer to develop... reason being: 
there's just no way that VBA can compete with the .NET base classes.

Now if were creating bound forms with bound controls, then yes - MS Access 
dev time will be substantially lower than in .NET because one would have to 
make the .NET form "data aware" while MS Access forms are data aware right 
out of the box. My point: each product will "lose" the productivity game in 
the other's neighborhood. MS Access shines when it comes to bound controls. 
But put it up against an unbound scenario with complex busienss logic or 
work flows and suddenly life with MS Access becomes very difficult... and 
.NET dev time would easily be quicker than Access....

RE:
<< He is the technical person for a largish consulting company in Sydney 
Australia >>
So am I (just not in Australia!), and you can see that I was incorrect about 
some things!

-Jordan















Return to dotnet framework

 

Who is online

Users browsing this forum: No registered users and 91 guest