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
0
PMK
6/3/2007 4:10:10 AM
access 16762 articles. 2 followers. Follow

88 Replies
1292 Views

Similar Articles

[PageSpeed] 51

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" <expat_th-usenet@yahoo.ca> wrote in message
news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
> 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


0
Baz
6/3/2007 6:40:33 AM
On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"
<bazz@REMOVEbcap.THEeuro1net.CAPScom> 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" <expat_th-usenet@yahoo.ca> wrote in message
>news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
>> 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
>
0
PMK
6/3/2007 7:18:47 AM
"PMK" <expat_th-usenet@yahoo.ca> wrote in message
news:eop4631v6nuduje7ii6rqjpr348gbt3atq@4ax.com...
> On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"
> <bazz@REMOVEbcap.THEeuro1net.CAPScom> 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?


0
Baz
6/3/2007 8:42:06 AM
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" <expat_th-usenet@yahoo.ca> wrote in message 
news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
>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 


0
Tore
6/3/2007 9:22:43 AM
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
0
PMK
6/3/2007 11:48:51 AM
On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
<bazz@REMOVEbcap.THEeuro1net.CAPScom> 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
0
PMK
6/3/2007 1:13:13 PM
On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" <tgyl@nospam.nospam> 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
0
PMK
6/3/2007 1:21:04 PM
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" <expat_th-usenet@yahoo.ca> wrote in message 
news:otf56352qf02ekvp2dns3ak0dc0utermue@4ax.com...
> On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" <tgyl@nospam.nospam> 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 


0
Norman
6/3/2007 3:21:41 PM
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.



0
Jim
6/3/2007 4:10:02 PM
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
0
PeteCresswell
6/3/2007 5:32:16 PM
> 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 


0
Robert
6/3/2007 5:40:18 PM
> 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 


0
Robert
6/3/2007 5:43:07 PM
> 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 


0
Robert
6/3/2007 5:45:40 PM
>    - 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 


0
Robert
6/3/2007 5:49:43 PM
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
0
PeteCresswell
6/3/2007 6:11:18 PM
> 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) ? 


0
Robert
6/3/2007 6:23:41 PM
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
0
PeteCresswell
6/3/2007 7:03:22 PM
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
0
PeteCresswell
6/3/2007 7:18:49 PM
> 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
pleaseNOOSpamKallal@msn.com


0
Albert
6/3/2007 7:28:52 PM
....NOBODY expects the Spanish Inquisition! Our chief weapon is 
surprise...surprise and fear...fear and surprise.... Our two weapons are 
fear and surprise...and ruthless efficiency.... Our *three* weapons are 
fear, surprise, and ruthless efficiency...and an almost fanatical devotion 
to the Pope.... Our *four*...no... *Amongst* our weapons....

So... How about: "Amongst my reasons are such diverse elemets as..." <g>

Cheers!
Fred Boer

"Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
news:%23oJ7jxgpHHA.3252@TK2MSFTNGP05.phx.gbl...
>> 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) ?
> 


0
Fred
6/3/2007 8:34:07 PM
On Sun, 3 Jun 2007 16:34:07 -0400, "Fred Boer" <fredboer1@NOyahooSPAM.com>
wrote:

>...NOBODY expects the Spanish Inquisition! 

or... given the off-topic posts that have been turning up here...

NOBODY expects the Spamish imposition!

             John W. Vinson [MVP]
0
John
6/3/2007 9:20:35 PM
"PMK" <expat_th-usenet@yahoo.ca> wrote in message 
news:otf56352qf02ekvp2dns3ak0dc0utermue@4ax.com...
> On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" <tgyl@nospam.nospam> 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

I use stored procedures on SQL Server a lot. They perform fast and are easy 
to debug. If you dont know them look into SQL Server Help. I use stored 
procedures to download data to the Access .adp client as well as for 
inserts, updates and deletes on SQL Server. Once the stored procedure is 
established on SQL Server, I will normally use ADO to run it from the Access 
client. You can learn som ADO here: http://www.w3schools.com/ado/default.asp

My code in an Access forms module to call a stored procedure with parameters 
could be something like this:

Dim CMD As New ADODB.Command, OwnerID As New ADODB.Parameter, YearID As New 
ADODB.Parameter, _

AccountName As New ADODB.Parameter, RetAccountID As New ADODB.Parameter


CMD.ActiveConnection = CurrentProject.Connection

CMD.CommandType = adCmdStoredProc

CMD.CommandText = "MSP_InsertCustomerAccount" 'The name of the stored 
procedure

Set OwnerID = CMD.CreateParameter("OwnerID", adInteger, adParamInput, , 
Forms!Menu.cboCompany)

CMD.Parameters.Append OwnerID

Set YearID = CMD.CreateParameter("YearID", adInteger, adParamInput, , 
Forms!Menu.cboFiscalYear)

CMD.Parameters.Append YearID

Set AccountName = CMD.CreateParameter("AccountName", adVarChar, 
adParamInput, 100, Me.txtName)

CMD.Parameters.Append AccountName

Set RetAccountID = CMD.CreateParameter("AccountID", adInteger, 
adParamOutput)

CMD.Parameters.Append RetAccountID

CMD.Execute

You can use a stored procedure as a recordsource of your form, but this 
would make it a bound form. What you also could do is to download data to an 
ADO recordset in your .adp client and use the recordset data to populate an 
unbound form.

You call a stored procedure that returns some recordset. Sample code above 
can be used for this. You have to add/change some lines of code:

DIM RS as new ADODB.Recordset

<Then lines as in example above>

Set RS = CMD.Execute in stead of CMD.Execute

If the stored procedure returns data they will go into the recordset RS, and 
you can use the RS recordset data to update controls of your unbound forms.

Normally one would add some errorhandling as well.

Regards

Tore




0
Tore
6/3/2007 11:13:37 PM
Per Tore:
>I use stored procedures on SQL Server..... They ... are easy 
>to debug.

Compared to VBA code - where I can pause the execution, examine
values, and single-step the code - I find stored procedures very
time-consuming to debug.   Kind of like CoBOL without dumps or
traces.

Do  you have any special tools for debugging?

-- 
PeteCresswell
0
PeteCresswell
6/3/2007 11:52:17 PM
That sounds like something Bush would say. :-)


Rob

"Fred Boer" <fredboer1@NOyahooSPAM.com> wrote in message 
news:OrO1D6hpHHA.4632@TK2MSFTNGP04.phx.gbl...
> ...NOBODY expects the Spanish Inquisition! Our chief weapon is 
> surprise...surprise and fear...fear and surprise.... Our two weapons are 
> fear and surprise...and ruthless efficiency.... Our *three* weapons are 
> fear, surprise, and ruthless efficiency...and an almost fanatical devotion 
> to the Pope.... Our *four*...no... *Amongst* our weapons....
>
> So... How about: "Amongst my reasons are such diverse elemets as..." <g>
>
> Cheers!
> Fred Boer
>
> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
> news:%23oJ7jxgpHHA.3252@TK2MSFTNGP05.phx.gbl...
>>> 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) ?
>>
>
> 


0
Robert
6/4/2007 2:13:30 AM
"PMK" <expat_th-usenet@yahoo.ca> wrote in message
news:71f563ltg0e8qa37pljl525u0i4ae0afvd@4ax.com...
> On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
> <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote:
>
> 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.
>

What will not work with subforms?  You've lost me.

> >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

Ohhhhh I begin to see where you are coming from.  You're talking about
entering records in both a main form and a subform as a single logical
transaction.  Not a requirement I have often encountered, although I have
needed to do it once or twice.  Would be interesting to hear more about your
circumstances.

Presumably when you use local tables in an mdb, temporary tables in SQL
Server or whatever, you are binding forms to them?  Otherwise why use tables
at all as your "temporary" repository?


0
Baz
6/4/2007 6:38:55 AM
Hi Robert,

Yes, I had a good go at doing that when the form's Recordset property was
first exposed to use, it was unusable, Access crashed all over the place.

"Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message
news:%23gMbZggpHHA.4132@TK2MSFTNGP02.phx.gbl...
> > 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
>
>


0
Baz
6/4/2007 6:42:37 AM
On Mon, 4 Jun 2007 01:13:37 +0200, "Tore" <tgyl@nospam.nospam> wrote:

>
>"PMK" <expat_th-usenet@yahoo.ca> wrote in message 
>news:otf56352qf02ekvp2dns3ak0dc0utermue@4ax.com...
>> On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" <tgyl@nospam.nospam> 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?


Tore, 

I am familiar with and use stored procedures. I meant examples of what
you mean by:  "Vs.net provides a lot more functionality for windows
clients than access."

Peter
0
PMK
6/4/2007 8:28:45 AM
On Mon, 4 Jun 2007 07:38:55 +0100, "Baz"
<bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote:

>
>Ohhhhh I begin to see where you are coming from.  You're talking about
>entering records in both a main form and a subform as a single logical
>transaction.  Not a requirement I have often encountered, although I have

I'm not sure how you could avoid it other than (off the top of my
head) putting the main form data onto a subform also. Anyway, in my
situation users enter main form data and then go on to enter subform
data. That is in a perfect world. They may try to enter the subform
data first which sets off an unhappy chain of events in bound forms.

Yes these (sub)forms are bound also, but not to the 'permanent' tables
so nothing is entered into the db until the operator (and my
validation code) has clearly indicated that the data is cleared to be
processed. BTW, deletes are often not treated casually and may only
allowed by certain operators and even then tracked so the
unintentional saving of a record is not a trivial event.

I may also deal with this in a variety of other ways, including hiding
subforms until essential data is entered. Sometimes that works well -
sometimes not. These strategies can't be divorced from the real world
situation. I mean you have to put yourself in the data entry person's
shoes and tailor the form to their skills, needs and working patterns
and also anticipate the kind of mistakes they will probably make and
figure out the best way to recover from them.

>needed to do it once or twice.  Would be interesting to hear more about your
>circumstances.

Maybe it is just a difference in style. I did not look for ways to
avoid this. It (unbound forms) seemed the best way of the various
alternatives to make the users the most productive and avoid data
entry errors and frustrations, particularly as my users  are mostly
not native English speakers nor particularly computer savvy
-suggesting using the ESC key to reverse a data entry would just be a
waste of time as would be suggesting using the built in Access menus,
which I do not expose to them. I don't regret it - the system works
well, is easy for them, and in fact data entry errors and service
calls were few (I am thinking of the app with the heaviest use of
unbound forms).

>Presumably when you use local tables in an mdb, temporary tables in SQL
>Server or whatever, you are binding forms to them?  Otherwise why use tables
>at all as your "temporary" repository?

Yes, the subforms are always bound to temporary tables - either Access
or MS SQL temp tables or tables used to store the data temporarily
until it is written to the main tables. The main form may or may not
be. I've also tried binding to recordsets with mixed results. For me,
an added advantage of using tables over code is it is easier that way
for me to go back a year or two or three later and quickly refresh
myself as to what the logic in that part of the application is. 

I find all the comments about my approach being the worst of two
worlds interesting. To me that implies I not only wasted a lot of time
but also produced an inferior product. Yet I've taken on jobs that
others have tried and failed to complete and produced a result that
has satisfied the requirements of the clients which is demonstrated
not only in their initial remarks and experiences, but by the fact
they by and large have continued to use and rely on the apps for years
and years. 

In fact, other than perhaps a slicker look using VB, I can't see how
the apps could be better! And with the last and most complex one I had
a lot of time to mull over that, as I worked as I.T. Admin for that
client for 5 years after creating the app, did some tweaking on it in
that time, but never had cause to question the underlying
construction, including form strategies.

It might be the worst of one or even two worlds for a completely
different applcation though - which could be said of almost any
approach. ;-)

Peter
0
PMK
6/4/2007 9:27:24 AM
On Sun, 3 Jun 2007 08:21:41 -0700, "Norman Yuan" <NotReal@NotReal.not>
wrote:


>    - 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. 

Actually my question (it's in the subject line) regards windows forms
only. 

> Do not mention Access DAP, it is useless.

Do you mean ADP? If so, sorry but that statement is not only wrong,
it's silly.If you want to defend it, then how about some facts and not
just a 'don't mention it'? 

It's not useless to my clients and one in particular that has been
very dependent on an ADP I did for them seven years ago that has given
them a huge competitive edge on their competition. If that app stops
working, then they stop working and neither has happened other than
from hardware failures.  

Now DAP, whatever that is, may indeed be useless but you have to tell
us what is is first. ;-).

Peter 
0
PMK
6/4/2007 9:57:42 AM
PMK wrote:
> Do you mean ADP? If so, sorry but that statement is not only wrong,
> it's silly.If you want to defend it, then how about some facts and not
> just a 'don't mention it'?
>
> It's not useless to my clients and one in particular that has been
> very dependent on an ADP I did for them seven years ago that has given
> them a huge competitive edge on their competition. If that app stops
> working, then they stop working and neither has happened other than
> from hardware failures.
>
> Now DAP, whatever that is, may indeed be useless but you have to tell
> us what is is first. ;-).
>
> Peter

An HTML form produced from Access.  The fact that you've never heard of them is 
a pretty good indicator of how useful they are.

-- 
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt   at   Hunter   dot   com 


0
Rick
6/4/2007 11:23:20 AM
"PMK" <expat_th-usenet@yahoo.ca> wrote in message
news:9bj763906avse0hu030pm9tcvi8p9429jo@4ax.com...
> On Mon, 4 Jun 2007 07:38:55 +0100, "Baz"
> <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote:
>
> >
> >Ohhhhh I begin to see where you are coming from.  You're talking about
> >entering records in both a main form and a subform as a single logical
> >transaction.  Not a requirement I have often encountered, although I have
>
> I'm not sure how you could avoid it other than (off the top of my
> head) putting the main form data onto a subform also. Anyway, in my
> situation users enter main form data and then go on to enter subform
> data. That is in a perfect world. They may try to enter the subform
> data first which sets off an unhappy chain of events in bound forms.
>

The way I stop subform records being entered when there's no parent record
is very simple: in the parent form's Current event, one line of code
disables the subform control if the parent form's NewRecord property is
True, and one line of code in the parent's AfterInsert event enables the
subform control.  Thus it is impossible to enter data into the subform
unless the parent record has first been entered and saved.

> Yes these (sub)forms are bound also, but not to the 'permanent' tables
> so nothing is entered into the db until the operator (and my
> validation code) has clearly indicated that the data is cleared to be
> processed. BTW, deletes are often not treated casually and may only
> allowed by certain operators and even then tracked so the
> unintentional saving of a record is not a trivial event.
>

You either validate the data in the form, or you validate the data in your
"temporary" tables.  Either way, if it passes validation it's gonna finish
up in the permanent tables, and if it was entered in error it's gonna have
to be deleted.  I don't see how the "temporary" tables help at all.

If you want the operator to always explicitly request a save (i.e. you want
to stop Access' default behaviour of automatically saving the record when,
say, closing the form or cycling to another record) then it's very easy to
add, say, a Save button, and to have the BeforeUpdate event cancel itself
unless it was initiated by the Save button.

> I may also deal with this in a variety of other ways, including hiding
> subforms until essential data is entered. Sometimes that works well -
> sometimes not. These strategies can't be divorced from the real world
> situation. I mean you have to put yourself in the data entry person's
> shoes and tailor the form to their skills, needs and working patterns
> and also anticipate the kind of mistakes they will probably make and
> figure out the best way to recover from them.
>

Wizard-style data entry (which normally would involve unbound forms) is good
way of handling repetitive data entry tasks which need to be done quickly
and accurately.  However, I would normally also have a full-blown bound form
to enquire upon the data, and for more sophisticated users to perform more
complex data entry which doesn't follow the path that the wiz takes.
Although, of course, this is all highly dependent upon the business
requirements.

>
> Maybe it is just a difference in style. I did not look for ways to
> avoid this. It (unbound forms) seemed the best way of the various
> alternatives to make the users the most productive and avoid data
> entry errors and frustrations, particularly as my users  are mostly
> not native English speakers nor particularly computer savvy
> -suggesting using the ESC key to reverse a data entry would just be a
> waste of time as would be suggesting using the built in Access menus,
> which I do not expose to them. I don't regret it - the system works
> well, is easy for them, and in fact data entry errors and service
> calls were few (I am thinking of the app with the heaviest use of
> unbound forms).
>

It's very easy to put a great big "Undo" button on a form, and I often do.
I never expose built-in Access menus either, but it's very easy to add built
in Access menu options (such as Undo) to your own custom menus.

I'm not suggesting you should regret using unbound forms, that wasn't the
point I started off trying to make.  My point is that if you are always or
mostly using unbound forms then Access is the wrong tool for the job.

> Yes, the subforms are always bound to temporary tables - either Access
> or MS SQL temp tables or tables used to store the data temporarily
> until it is written to the main tables. The main form may or may not
> be. I've also tried binding to recordsets with mixed results. For me,
> an added advantage of using tables over code is it is easier that way
> for me to go back a year or two or three later and quickly refresh
> myself as to what the logic in that part of the application is.
>

So you ARE using bound forms!

> I find all the comments about my approach being the worst of two
> worlds interesting.

But it seems that your approach is not what you said it was: you ARE using
bound forms!

> In fact, other than perhaps a slicker look using VB, I can't see how
> the apps could be better! And with the last and most complex one I had
> a lot of time to mull over that, as I worked as I.T. Admin for that
> client for 5 years after creating the app, did some tweaking on it in
> that time, but never had cause to question the underlying
> construction, including form strategies.
>

So why are you even considering changing to dotnet?  You said above that
your subforms are always bound to tables.  Whether they are "temporary"
tables matters not a jot: by using bound subforms you are using powerful
Access features which are not available in dotnet (or indeed any other
development environment that I am aware of).



0
Baz
6/4/2007 12:04:37 PM
"PMK" <expat_th-usenet@yahoo.ca> wrote in message
news:e1o76352bopncp3vufnpaklfq0f9clu7cn@4ax.com...

> > Do not mention Access DAP, it is useless.
>
> Do you mean ADP? If so, sorry but that statement is not only wrong,
> it's silly.If you want to defend it, then how about some facts and not
> just a 'don't mention it'?
>

He means what he said: DAP = Data Access Pages.  If you have Access 2000, or
2002, or 2003, look it up in Help.  Or click on the "Pages" button at the
left-hand side of the database window and see what that does for you
(although he's right, they ARE useless).

Some people do believe that ADP's are also useless, and although I don't
agree (having done lot of them myself), there's a strong argument that, if
not useless, they are at least pointless.  Before
ADP's were invented in Access 2000, we already had ODBC linked tables which
were, and still are, a very good way of using Access with SQL Server, or
indeed ANY database for which you can find ODBC drivers.  There might have
been some point to ADP's if Microsoft had carried through it's plan of
dropping Jet and migrating wholly to SQL Server but, in typical Microsoft
fashion, the plan was short-lived.  The new accdb format with revamped Jet
and DAO is the new way forward, with good ol' ODBC linked tables the
preferred way of using server database engines.  Infuriatingly for those of
us who've made a significant investment in them, ADP's are on the road to
nowhere.


0
Baz
6/4/2007 12:22:46 PM
On Mon, 04 Jun 2007 11:23:20 GMT, "Rick Brandt"
<rickbrandt2@hotmail.com> wrote:

>PMK wrote:
>> Do you mean ADP? If so, sorry but that statement is not only wrong,
>> it's silly.If you want to defend it, then how about some facts and not
>> just a 'don't mention it'?
>>
>> It's not useless to my clients and one in particular that has been
>> very dependent on an ADP I did for them seven years ago that has given
>> them a huge competitive edge on their competition. If that app stops
>> working, then they stop working and neither has happened other than
>> from hardware failures.
>>
>> Now DAP, whatever that is, may indeed be useless but you have to tell
>> us what is is first. ;-).
>>
>> Peter
>
>An HTML form produced from Access.  The fact that you've never heard of them is 
>a pretty good indicator of how useful they are.

Oh, now I remember them - I think I devoted about 8 minutes to them
once. Man,that was ages ago. I mean, that is just trivia now. ;-)

 My excuse for the rant is I don't think I ever saw the DAP acronym,
they would be off topic so didn't expect that they would be mentioned,
and with all the discussion of ADP made a wrong assumption.
Nevertheless, my bad and apologies to the OP.

Peter
0
PMK
6/4/2007 12:38:10 PM
 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?

Yes.


> 2) What do you think your own ratio of MS Access man hours to
>   VB.NET man hours on the same application would be?
> -------------------------------------------------------------
> -- 


The ratio is 1.3.  That is, 100 hours in Access versus 130 hours in C#.

By the way, I use C#.

Jim


0
Jim
6/4/2007 1:03:52 PM
yes, Access Data Projects are a much better solution than .NET forms

plug and play
easy development

it's really really simple

FILE, NEW, PROJECT EXISTING DATA

On Jun 2, 9:10 pm, PMK <expat_th-use...@yahoo.ca> wrote:
> 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


0
aaron
6/4/2007 4:27:05 PM
What don't i like about VS.net?

It's slow
in development and execution


it's not database-centric
it's not as powerful as crystal reports



On Jun 3, 12:18 am, PMK <expat_th-use...@yahoo.ca> wrote:
> On Sun, 3 Jun 2007 07:40:33 +0100, "Baz"
>
> <b...@REMOVEbcap.THEeuro1net.CAPScom> 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" <expat_th-use...@yahoo.ca> wrote in message
> >news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
> >> 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- Hide quoted text -
>
> - Show quoted text -


0
aaron
6/4/2007 4:27:44 PM
local tables are not a feature kid; I mean are you fucking retarded?


seriously bud

if you need a 'local table' in ADP then you need to learn how to use
TSQL
I mean get real bud



On Jun 3, 6:13 am, PMK <expat_th-use...@yahoo.ca> wrote:
> On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
>
> <b...@REMOVEbcap.THEeuro1net.CAPScom> 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- Hide quoted text -
>
> - Show quoted text -


0
aaron
6/4/2007 4:29:21 PM
forms bound to temp tables on C?

now you're talkingf about a 3-tier Access Database mess?

Are you fucking for real?
just use ADP and use NOLOCK everywhere you go



On Jun 3, 10:32 am, "(PeteCresswell)" <x...@y.Invalid> wrote:
> 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


0
aaron
6/4/2007 4:30:20 PM
> 
> 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.
> 

You have to buy the tools. Then the distribution is free.
Except that there has been a free version of VS for a couple
of years now, and the free version of the Access redistributable
(for Access 2007) is not available yet.

(david)

0
DAVID
6/5/2007 12:42:44 AM
"Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote

 >> 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.

Most of us have long since tired of trying to explain database to 
non-database programmers, most of whom seem to prefer arguing and justifying 
to themselves that the way they are used to working is best. That is, 
instead of seriously considering that Access is a database application 
generator but the tools they are used to using are general purpose 
application generators which can, by the way, do some database.

And, as I am not interested in pointless argument, I'm removing the 
crossposted newsgroups from this reply. Frankly, if they want to use 
bulldozers and steamshovels to build a flowerbed, it's OK with me.

 Larry Linson
 Microsoft Access MVP



0
Larry
6/5/2007 7:24:06 AM
"PMK" <expat_th-usenet@yahoo.ca> wrote in message 
news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
>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?

Use appropriate tools for the job at hand: In general, for "normal business 
database applications" in a single-user, multi-user, or client-server 
environment, Access is the better tool; for "web based" or distributed 
enterprise applications, the DotNet environment is appropriate.

For applications which can be done with Access, there is a significant 
advantage in time and effort to create and maintain the application over 
doing the same thing in DotNet.

For applications which could be done in Access but for which the users or 
the developers believe that user interface "glitz and glitter" is important, 
and for which finances are available to license the third-party tools that 
make it possible to create that glitz and glitter, and for which 
implementation costs are secondary, then DotNet is the tool you want. {None 
of my clients/customers, BTW, ever considered implementation costs to be 
"secondary" nor were willing to pay much (some of them not willing to pay 
even a nanocent) for "glitz and glitter".}

For applications which can only be done with software tools of "grander 
scope", Access just isn't suitable so the comparison is not worthwhile. 
There are many who prefer other "grander scope" development 
tools/environments over DotNet -- as my work is all "normal business 
applications" for which Access is appropriate, I don't have a dog in that 
fight.

  Larry Linson
  Microsoft Access MVP 


0
Larry
6/5/2007 7:44:54 AM
Larry Linson wrote:
> "PMK" <expat_th-usenet@yahoo.ca> wrote in message 
> news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
>> 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?
> 
> Use appropriate tools for the job at hand: In general, for "normal business 
> database applications" in a single-user, multi-user, or client-server 
> environment, Access is the better tool; for "web based" or distributed 
> enterprise applications, the DotNet environment is appropriate.
> 
> For applications which can be done with Access, there is a significant 
> advantage in time and effort to create and maintain the application over 
> doing the same thing in DotNet.
> 
> For applications which could be done in Access but for which the users or 
> the developers believe that user interface "glitz and glitter" is important, 
> and for which finances are available to license the third-party tools that 
> make it possible to create that glitz and glitter, and for which 
> implementation costs are secondary, then DotNet is the tool you want. {None 
> of my clients/customers, BTW, ever considered implementation costs to be 
> "secondary" nor were willing to pay much (some of them not willing to pay 
> even a nanocent) for "glitz and glitter".}
> 
> For applications which can only be done with software tools of "grander 
> scope", Access just isn't suitable so the comparison is not worthwhile. 
> There are many who prefer other "grander scope" development 
> tools/environments over DotNet -- as my work is all "normal business 
> applications" for which Access is appropriate, I don't have a dog in that 
> fight.
> 
>   Larry Linson
>   Microsoft Access MVP 
> 
> 

I think development was faster with Access only in the early age of 
..NET. With .NET you have much greater possibilities to gradually 
accumulate really reusable pieces of code or create automated code 
generation tools which significantly outperform Access in almost any aspect.

-- 


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

0
Thomas
6/5/2007 9:29:30 PM
In which case, it may get into whether you're a "power" .NET user or not.

That said, however, you have at least some of the same capabilities in 
Access, as (unlike VB6 AFAIK) you can automate a good amount of form/report 
generation if you have the need to do so.  Conceivably, you could design a 
form entirely by VBA code (much like the existing Wizards already do), 
though there aren't all that many cases where you would actually do so, as a 
general rule.  More often, this sort of thing is used to iterate through all 
Access forms to apply certain design rules (change all fonts on all forms to 
Arial, as an example).

While not quite the same as the above, one example of this sort of thing 
that I've done before is to write code which will size Access controls to 
the largest size required to fit the same text for both 96 DPI and 120 DPI, 
as well as auto-sizing combo/listboxes to their largest element.  This gets 
attached to a custom button in your toolbar, and as you can imagine, becomes 
VERY useful in Access forms development.

Is this the sort of thing you're talking about doing in .NET?  I haven't 
tried it since the early days, so I'm not sure of its more recent 
capabilities.



Rob

"Thomas" <thomas@nconstruct.com> wrote in message 
news:eIG9hi7pHHA.196@TK2MSFTNGP05.phx.gbl...
> Larry Linson wrote:
>> "PMK" <expat_th-usenet@yahoo.ca> wrote in message 
>> news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
>>> 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?
>>
>> Use appropriate tools for the job at hand: In general, for "normal 
>> business database applications" in a single-user, multi-user, or 
>> client-server environment, Access is the better tool; for "web based" or 
>> distributed enterprise applications, the DotNet environment is 
>> appropriate.
>>
>> For applications which can be done with Access, there is a significant 
>> advantage in time and effort to create and maintain the application over 
>> doing the same thing in DotNet.
>>
>> For applications which could be done in Access but for which the users or 
>> the developers believe that user interface "glitz and glitter" is 
>> important, and for which finances are available to license the 
>> third-party tools that make it possible to create that glitz and glitter, 
>> and for which implementation costs are secondary, then DotNet is the tool 
>> you want. {None of my clients/customers, BTW, ever considered 
>> implementation costs to be "secondary" nor were willing to pay much (some 
>> of them not willing to pay even a nanocent) for "glitz and glitter".}
>>
>> For applications which can only be done with software tools of "grander 
>> scope", Access just isn't suitable so the comparison is not worthwhile. 
>> There are many who prefer other "grander scope" development 
>> tools/environments over DotNet -- as my work is all "normal business 
>> applications" for which Access is appropriate, I don't have a dog in that 
>> fight.
>>
>>   Larry Linson
>>   Microsoft Access MVP
>
> I think development was faster with Access only in the early age of .NET. 
> With .NET you have much greater possibilities to gradually accumulate 
> really reusable pieces of code or create automated code generation tools 
> which significantly outperform Access in almost any aspect.
>
> -- 
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
> 


0
Robert
6/5/2007 9:41:36 PM
"Thomas" <thomas@nconstruct.com> wrote

  > . . .
  > I think development was faster with Access only in the early age of
  > .NET. With .NET you have much greater possibilities to gradually
  > accumulate really reusable pieces of code or create automated code
  > generation tools which significantly outperform Access in almost any 
aspect.

Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, made 
friends in Redmond with that kind of reply.

I had a C-programmer colleague back at the "major computer manufacturer" 
from which I retired who said something similar about C, and then about C++, 
comparing it to PL/I, Basic, and then to Visual Basic and Access. He's 
likely saying the same about C#, now, but chances are the clients who can 
afford him are all doing distributed enterprise apps that are web-based.

The problem is that you _DO NEED_ to "gradually accumulate" (and 
purchase/license -- lots of purchasing/licensing going on in the DotNet 
world) reusable pieces of code or create automated code generation tools in 
order to do with any facility even the most basic of the database functions 
that are built in to Access, right out of the box. That is, if you re-create 
Access in DotNet, you'll almost catch up with "the real thing."

You do realize, don't you, that the statement "significantly outperform 
Access in almost any aspect" is essentially content-free, don't you? 
Frankly, my view is that "Access out of the box outperforms Visual Studio in 
creating normal business database applications for the single-user, 
multi-user, anc client-server environments". I know a few people who do both 
Access and DotNet, and they agree with me; the ones who don't are those who 
don't now use, or perhaps never have used, Access and think it's just a 
"junior version" of DotNet.

The essential functionality needed for controlling the application, 
navigating, and manipulating the database is ALREADY THERE with Access, so 
all you have to do is put in the business functions (and, unless you develop 
very similar applications for multiple businesses, it's not going to be 
useful, and depending on your agreement with your clients, may not be legal, 
to "package" their business functionality as "really reusable pieces of 
code".)

I spent some of the early part of my career creating development tools. It's 
interesting work, but it's not something an application developer should 
have to do in order to get decent development for their investment of time 
and effort, or to be able to accomplish what they need at all. It's a lot 
more productive for the application developer to develop applications, not 
tools, not create and accumulate libraries.

 Larry Linson
 Microsoft Access MVP



0
Larry
6/6/2007 12:29:57 AM
I have two things to say to you: linked subforms and continuous forms.

"Thomas" <thomas@nconstruct.com> wrote in message
news:eIG9hi7pHHA.196@TK2MSFTNGP05.phx.gbl...
> Larry Linson wrote:
> > "PMK" <expat_th-usenet@yahoo.ca> wrote in message
> > news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
> >> 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?
> >
> > Use appropriate tools for the job at hand: In general, for "normal
business
> > database applications" in a single-user, multi-user, or client-server
> > environment, Access is the better tool; for "web based" or distributed
> > enterprise applications, the DotNet environment is appropriate.
> >
> > For applications which can be done with Access, there is a significant
> > advantage in time and effort to create and maintain the application over
> > doing the same thing in DotNet.
> >
> > For applications which could be done in Access but for which the users
or
> > the developers believe that user interface "glitz and glitter" is
important,
> > and for which finances are available to license the third-party tools
that
> > make it possible to create that glitz and glitter, and for which
> > implementation costs are secondary, then DotNet is the tool you want.
{None
> > of my clients/customers, BTW, ever considered implementation costs to be
> > "secondary" nor were willing to pay much (some of them not willing to
pay
> > even a nanocent) for "glitz and glitter".}
> >
> > For applications which can only be done with software tools of "grander
> > scope", Access just isn't suitable so the comparison is not worthwhile.
> > There are many who prefer other "grander scope" development
> > tools/environments over DotNet -- as my work is all "normal business
> > applications" for which Access is appropriate, I don't have a dog in
that
> > fight.
> >
> >   Larry Linson
> >   Microsoft Access MVP
> >
> >
>
> I think development was faster with Access only in the early age of
> .NET. With .NET you have much greater possibilities to gradually
> accumulate really reusable pieces of code or create automated code
> generation tools which significantly outperform Access in almost any
aspect.
>
> -- 
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
>


0
Baz
6/6/2007 7:23:02 AM
Robert Morley wrote:
> In which case, it may get into whether you're a "power" .NET user or not.
> 
> That said, however, you have at least some of the same capabilities in 
> Access, as (unlike VB6 AFAIK) you can automate a good amount of form/report 
> generation if you have the need to do so.  Conceivably, you could design a 
> form entirely by VBA code (much like the existing Wizards already do), 
> though there aren't all that many cases where you would actually do so, as a 
> general rule.  More often, this sort of thing is used to iterate through all 
> Access forms to apply certain design rules (change all fonts on all forms to 
> Arial, as an example).
> 
> While not quite the same as the above, one example of this sort of thing 
> that I've done before is to write code which will size Access controls to 
> the largest size required to fit the same text for both 96 DPI and 120 DPI, 
> as well as auto-sizing combo/listboxes to their largest element.  This gets 
> attached to a custom button in your toolbar, and as you can imagine, becomes 
> VERY useful in Access forms development.
> 
> Is this the sort of thing you're talking about doing in .NET?  I haven't 
> tried it since the early days, so I'm not sure of its more recent 
> capabilities.
> 
> 
> 
> Rob

Rob, I agree it's a lot about question if somebody is a "power" .NET 
user or not. But this should not be an excuse for not to stick with .NET 
(it's easier to ride bike than drive car, too).

Otherwise, I've just wanted to point out that time needed to produce a 
business application could be on the .NET side. Of course you can do a 
lot of code generation things with VBA and you also get a lot of 
built-in wizards in Access, too.
As you say, form or report creating wizards are not of much use. In my 
opinion, developer should think in another way - his/hers job should be 
only to create code which demands hard brain work. Dropping textboxes 
and labels on the form, binding them to the database fields, arranging 
them on the gui controls etc. is not that type of work and it should be 
done automatically. Developer should focus only on the special 
customer's needs, business rules which are different for each 
application, some special gui controls etc.

-- 


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

0
Thomas
6/6/2007 7:42:10 AM
Larry Linson wrote:
> "Thomas" <thomas@nconstruct.com> wrote
> 
>   > . . .
>   > I think development was faster with Access only in the early age of
>   > .NET. With .NET you have much greater possibilities to gradually
>   > accumulate really reusable pieces of code or create automated code
>   > generation tools which significantly outperform Access in almost any 
> aspect.
> 
> Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, made 
> friends in Redmond with that kind of reply.
> 
> I had a C-programmer colleague back at the "major computer manufacturer" 
> from which I retired who said something similar about C, and then about C++, 
> comparing it to PL/I, Basic, and then to Visual Basic and Access. He's 
> likely saying the same about C#, now, but chances are the clients who can 
> afford him are all doing distributed enterprise apps that are web-based.
> 
> The problem is that you _DO NEED_ to "gradually accumulate" (and 
> purchase/license -- lots of purchasing/licensing going on in the DotNet 
> world) reusable pieces of code or create automated code generation tools in 
> order to do with any facility even the most basic of the database functions 
> that are built in to Access, right out of the box. That is, if you re-create 
> Access in DotNet, you'll almost catch up with "the real thing."
> 
> You do realize, don't you, that the statement "significantly outperform 
> Access in almost any aspect" is essentially content-free, don't you? 
> Frankly, my view is that "Access out of the box outperforms Visual Studio in 
> creating normal business database applications for the single-user, 
> multi-user, anc client-server environments". I know a few people who do both 
> Access and DotNet, and they agree with me; the ones who don't are those who 
> don't now use, or perhaps never have used, Access and think it's just a 
> "junior version" of DotNet.
> 
> The essential functionality needed for controlling the application, 
> navigating, and manipulating the database is ALREADY THERE with Access, so 
> all you have to do is put in the business functions (and, unless you develop 
> very similar applications for multiple businesses, it's not going to be 
> useful, and depending on your agreement with your clients, may not be legal, 
> to "package" their business functionality as "really reusable pieces of 
> code".)
> 
> I spent some of the early part of my career creating development tools. It's 
> interesting work, but it's not something an application developer should 
> have to do in order to get decent development for their investment of time 
> and effort, or to be able to accomplish what they need at all. It's a lot 
> more productive for the application developer to develop applications, not 
> tools, not create and accumulate libraries.
> 
>  Larry Linson
>  Microsoft Access MVP
> 
> 
> 

Larry, don't get me wrong. It's really not about being a DotNet fan (and 
I believe you can get friends in Redmond speaking friendly about Access, 
too). :-)

I do work right now (and was working for several years in the past) both 
with Access and .NET, and I'm just comparing both of the worlds.

Speaking about the licensing "problem" - I think we should calculate if 
this is really the drawback of the .NET. Most of the components typical 
developer needs are royalty free so you have to purchase only one piece 
of the license. For example, if you need rich gui components you will 
spend about $1000 but you will get very powerful tools which can 
significantly shorten development time - for both Windows and Web 
platform (not to mention enormous end-user capabilities). The same (or 
even cheaper) is with the refactoring or code generation tools etc. 
Comparing such sums with the earnings of developer (or company) is 
insignificant.

So, the question should not be if Access out of the box outperforms 
Visual Studio (also out of the box) for some type of applications. I 
agree it is probably true if we treat this question only theoretically 
but in the real world developer should calculate the whole costs of 
development. In the end everybody (at least in my opinion) realize that 
the only meaningful cost is the development time.

Therefore I see the only reasonable argument in behalf of Access the 
learning curve. Someone should consider if it's worth to spend more time 
learning .NET and OO programming, and get the chance to compete also in 
the enterprise applications market, or spend less time and stay limited 
with the Access capabilities and obsolete programming language.


-- 


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

0
Thomas
6/6/2007 9:03:47 AM
Baz wrote:
> I have two things to say to you: linked subforms and continuous forms.

Baz, I don't think this is an Access advantage. For example, look at 
those tutorials:
http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html

It's fast to create (at least as fast as Access), it has more features 
than Access etc.

This is only one approach - it's similar to Access' one (I don't like 
any of them, though). If you need n-tiered application it's better to do 
the dynamic grid creation. In both cases you can do it with VS out of 
the box or you can buy some 3rd party components.

-- 


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------

0
Thomas
6/6/2007 9:55:23 AM
Per Thomas:
>Dropping textboxes 
>and labels on the form, 

In .NET does the developer still have to create a text box and
then separately create/align a label for that text box?  Or do
they have an out-of-the-box textbox object whose label follows it
around like MS Access does?
-- 
PeteCresswell
0
PeteCresswell
6/6/2007 12:44:36 PM
Well I haven't got VS 2005 and I'm not likely to get it either (having
wasted a significant amount of my own money on upgrading from VS 6 to VS
2002/2003, and then concluding that it sucked so badly that I was simply not
interested in using it).

Nor am I impressed by a product which requires me to buy third-party add-ons
in order for it to be anywhere near usable.


"Thomas" <thomas@nconstruct.com> wrote in message
news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
> Baz wrote:
> > I have two things to say to you: linked subforms and continuous forms.
>
> Baz, I don't think this is an Access advantage. For example, look at
> those tutorials:
>
http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>
http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>
> It's fast to create (at least as fast as Access), it has more features
> than Access etc.
>
> This is only one approach - it's similar to Access' one (I don't like
> any of them, though). If you need n-tiered application it's better to do
> the dynamic grid creation. In both cases you can do it with VS out of
> the box or you can buy some 3rd party components.
>
> -- 
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
>


0
Baz
6/6/2007 12:46:50 PM
Baz, you can use free VS 2005 Express and don't buy any 3rd party 
component if you don't want, and you can still produce i.e. continuous 
forms with DataGridView component. This is not the best solution but 
either is not worse than Access (for which there is no free version at 
all).

IMO, a lot of 3rd party components *do* work very well - guys at 
Developer Express, ComponentOne, Infragistic etc. really produce very 
usable products. Serious developer should at least try them before judge 
about their usability or quality. They are also very cheap comparing to 
the price of developing only few percent of their features. Maybe it 
sounds like advertising but I really just buy them and use them, and I 
want to share good experience with other developers.


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Baz wrote:
> Well I haven't got VS 2005 and I'm not likely to get it either (having
> wasted a significant amount of my own money on upgrading from VS 6 to VS
> 2002/2003, and then concluding that it sucked so badly that I was simply not
> interested in using it).
> 
> Nor am I impressed by a product which requires me to buy third-party add-ons
> in order for it to be anywhere near usable.
> 
> 
> "Thomas" <thomas@nconstruct.com> wrote in message
> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>> Baz wrote:
>>> I have two things to say to you: linked subforms and continuous forms.
>> Baz, I don't think this is an Access advantage. For example, look at
>> those tutorials:
>>
> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>> It's fast to create (at least as fast as Access), it has more features
>> than Access etc.
>>
>> This is only one approach - it's similar to Access' one (I don't like
>> any of them, though). If you need n-tiered application it's better to do
>> the dynamic grid creation. In both cases you can do it with VS out of
>> the box or you can buy some 3rd party components.
>>
>> -- 
>>
>>
>> Regards,
>> Thomas
>>
>> -----------------------------------------
>> NConstruct - Intelligent Software Factory
>> http://www.nconstruct.com
>> -----------------------------------------
>>
> 
> 
0
Thomas
6/6/2007 1:12:20 PM
> (it's easier to ride bike than drive car, too).

Bad argument to make for me; I'm nearing 40, and I've never driven a car.  I 
use public transit for everything.  About half my friends don't drive, 
either, and my partner, who's a professional photographer, uses his bike as 
his company vehicle without a problem.

> As you say, form or report creating wizards are not of much use.

Actually, it wasn't me that said that, though for the most part, I agree. :)



Rob 


0
Robert
6/6/2007 2:43:54 PM
I think what Larry and I are trying to say is that for us, we find Access to 
vastly outperform .NET in terms of development time.

That said, however, it's possible that .NET 2005 can do it, but I, at least, 
haven't seen anything to prove that to me concretely, and I'm certainly not 
about to spend money, and months or years worth of time porting my existing 
business apps in the hopes that their might be some marginal gain to my 
ability to develop applications faster.  Even if we accept that development 
is faster, the additional time/learning curve required easily outweighs any 
advantage to .NET.

The performance of VB.NET also has yet to equal that of VB6/VBA, so that is 
a consideration as well.  The only way to get acceptable performance in many 
cases is to use unmanaged code, and I have no ambitions to learn C++.


Rob

"Thomas" <thomas@nconstruct.com> wrote in message 
news:OU4ZcmBqHHA.4152@TK2MSFTNGP04.phx.gbl...
> Larry Linson wrote:
>> "Thomas" <thomas@nconstruct.com> wrote
>>
>>   > . . .
>>   > I think development was faster with Access only in the early age of
>>   > .NET. With .NET you have much greater possibilities to gradually
>>   > accumulate really reusable pieces of code or create automated code
>>   > generation tools which significantly outperform Access in almost any 
>> aspect.
>>
>> Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, 
>> made friends in Redmond with that kind of reply.
>>
>> I had a C-programmer colleague back at the "major computer manufacturer" 
>> from which I retired who said something similar about C, and then about 
>> C++, comparing it to PL/I, Basic, and then to Visual Basic and Access. 
>> He's likely saying the same about C#, now, but chances are the clients 
>> who can afford him are all doing distributed enterprise apps that are 
>> web-based.
>>
>> The problem is that you _DO NEED_ to "gradually accumulate" (and 
>> purchase/license -- lots of purchasing/licensing going on in the DotNet 
>> world) reusable pieces of code or create automated code generation tools 
>> in order to do with any facility even the most basic of the database 
>> functions that are built in to Access, right out of the box. That is, if 
>> you re-create Access in DotNet, you'll almost catch up with "the real 
>> thing."
>>
>> You do realize, don't you, that the statement "significantly outperform 
>> Access in almost any aspect" is essentially content-free, don't you? 
>> Frankly, my view is that "Access out of the box outperforms Visual Studio 
>> in creating normal business database applications for the single-user, 
>> multi-user, anc client-server environments". I know a few people who do 
>> both Access and DotNet, and they agree with me; the ones who don't are 
>> those who don't now use, or perhaps never have used, Access and think 
>> it's just a "junior version" of DotNet.
>>
>> The essential functionality needed for controlling the application, 
>> navigating, and manipulating the database is ALREADY THERE with Access, 
>> so all you have to do is put in the business functions (and, unless you 
>> develop very similar applications for multiple businesses, it's not going 
>> to be useful, and depending on your agreement with your clients, may not 
>> be legal, to "package" their business functionality as "really reusable 
>> pieces of code".)
>>
>> I spent some of the early part of my career creating development tools. 
>> It's interesting work, but it's not something an application developer 
>> should have to do in order to get decent development for their investment 
>> of time and effort, or to be able to accomplish what they need at all. 
>> It's a lot more productive for the application developer to develop 
>> applications, not tools, not create and accumulate libraries.
>>
>>  Larry Linson
>>  Microsoft Access MVP
>>
>>
>>
>
> Larry, don't get me wrong. It's really not about being a DotNet fan (and I 
> believe you can get friends in Redmond speaking friendly about Access, 
> too). :-)
>
> I do work right now (and was working for several years in the past) both 
> with Access and .NET, and I'm just comparing both of the worlds.
>
> Speaking about the licensing "problem" - I think we should calculate if 
> this is really the drawback of the .NET. Most of the components typical 
> developer needs are royalty free so you have to purchase only one piece of 
> the license. For example, if you need rich gui components you will spend 
> about $1000 but you will get very powerful tools which can significantly 
> shorten development time - for both Windows and Web platform (not to 
> mention enormous end-user capabilities). The same (or even cheaper) is 
> with the refactoring or code generation tools etc. Comparing such sums 
> with the earnings of developer (or company) is insignificant.
>
> So, the question should not be if Access out of the box outperforms Visual 
> Studio (also out of the box) for some type of applications. I agree it is 
> probably true if we treat this question only theoretically but in the real 
> world developer should calculate the whole costs of development. In the 
> end everybody (at least in my opinion) realize that the only meaningful 
> cost is the development time.
>
> Therefore I see the only reasonable argument in behalf of Access the 
> learning curve. Someone should consider if it's worth to spend more time 
> learning .NET and OO programming, and get the chance to compete also in 
> the enterprise applications market, or spend less time and stay limited 
> with the Access capabilities and obsolete programming language.
>
>
> -- 
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
> 


0
Robert
6/6/2007 2:51:42 PM
You SERIOUSLY haven't looked at continuous forms and subforms if you think 
any type of grid control holds a candle to them.


Rob

"Thomas" <thomas@nconstruct.com> wrote in message 
news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
> Baz wrote:
>> I have two things to say to you: linked subforms and continuous forms.
>
> Baz, I don't think this is an Access advantage. For example, look at those 
> tutorials:
> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>
> It's fast to create (at least as fast as Access), it has more features 
> than Access etc.
>
> This is only one approach - it's similar to Access' one (I don't like any 
> of them, though). If you need n-tiered application it's better to do the 
> dynamic grid creation. In both cases you can do it with VS out of the box 
> or you can buy some 3rd party components.
>
> -- 
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
> 


0
Robert
6/6/2007 2:52:51 PM
Yep, that sounds like advertising.  As I said, I own VS 2003 Professional
and I consider it to have been a complete waste of money.  I do not believe
that VS 2005 can be so much better that it is worth me spending any time on
it, and I'm certainly not going to waste any money buying add-ons for it.
I'd rather put my efforts into continuing my investigations into Delphi (not
that I see Delphi as a serious contender to Access either for database
applications, it's just that, for the odd occasion when I do something for
which I don't consider Access suitable, I'd like to have a serious and
current alternative to VB6).

"Thomas" <thomas@nconstruct.com> wrote in message
news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
> Baz, you can use free VS 2005 Express and don't buy any 3rd party
> component if you don't want, and you can still produce i.e. continuous
> forms with DataGridView component. This is not the best solution but
> either is not worse than Access (for which there is no free version at
> all).
>
> IMO, a lot of 3rd party components *do* work very well - guys at
> Developer Express, ComponentOne, Infragistic etc. really produce very
> usable products. Serious developer should at least try them before judge
> about their usability or quality. They are also very cheap comparing to
> the price of developing only few percent of their features. Maybe it
> sounds like advertising but I really just buy them and use them, and I
> want to share good experience with other developers.
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
>
>
>
>
> Baz wrote:
> > Well I haven't got VS 2005 and I'm not likely to get it either (having
> > wasted a significant amount of my own money on upgrading from VS 6 to VS
> > 2002/2003, and then concluding that it sucked so badly that I was simply
not
> > interested in using it).
> >
> > Nor am I impressed by a product which requires me to buy third-party
add-ons
> > in order for it to be anywhere near usable.
> >
> >
> > "Thomas" <thomas@nconstruct.com> wrote in message
> > news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
> >> Baz wrote:
> >>> I have two things to say to you: linked subforms and continuous forms.
> >> Baz, I don't think this is an Access advantage. For example, look at
> >> those tutorials:
> >>
> >
http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
> >
http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
> >> It's fast to create (at least as fast as Access), it has more features
> >> than Access etc.
> >>
> >> This is only one approach - it's similar to Access' one (I don't like
> >> any of them, though). If you need n-tiered application it's better to
do
> >> the dynamic grid creation. In both cases you can do it with VS out of
> >> the box or you can buy some 3rd party components.
> >>
> >> -- 
> >>
> >>
> >> Regards,
> >> Thomas
> >>
> >> -----------------------------------------
> >> NConstruct - Intelligent Software Factory
> >> http://www.nconstruct.com
> >> -----------------------------------------
> >>
> >
> >


0
Baz
6/6/2007 3:00:23 PM
I'd like to hear some examples where continuous forms outperforms .NET 
grids?


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
> You SERIOUSLY haven't looked at continuous forms and subforms if you think 
> any type of grid control holds a candle to them.
> 
> 
> Rob
> 
> "Thomas" <thomas@nconstruct.com> wrote in message 
> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>> Baz wrote:
>>> I have two things to say to you: linked subforms and continuous forms.
>> Baz, I don't think this is an Access advantage. For example, look at those 
>> tutorials:
>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>
>> It's fast to create (at least as fast as Access), it has more features 
>> than Access etc.
>>
>> This is only one approach - it's similar to Access' one (I don't like any 
>> of them, though). If you need n-tiered application it's better to do the 
>> dynamic grid creation. In both cases you can do it with VS out of the box 
>> or you can buy some 3rd party components.
>>
>> -- 
>>
>>
>> Regards,
>> Thomas
>>
>> -----------------------------------------
>> NConstruct - Intelligent Software Factory
>> http://www.nconstruct.com
>> -----------------------------------------
>>
> 
> 
0
Thomas
6/6/2007 3:14:03 PM
I still don't know the reasons you were not satisfied with VS/.NET 
(except that with learning time)?


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Baz wrote:
> Yep, that sounds like advertising.  As I said, I own VS 2003 Professional
> and I consider it to have been a complete waste of money.  I do not believe
> that VS 2005 can be so much better that it is worth me spending any time on
> it, and I'm certainly not going to waste any money buying add-ons for it.
> I'd rather put my efforts into continuing my investigations into Delphi (not
> that I see Delphi as a serious contender to Access either for database
> applications, it's just that, for the odd occasion when I do something for
> which I don't consider Access suitable, I'd like to have a serious and
> current alternative to VB6).
> 
> "Thomas" <thomas@nconstruct.com> wrote in message
> news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>> component if you don't want, and you can still produce i.e. continuous
>> forms with DataGridView component. This is not the best solution but
>> either is not worse than Access (for which there is no free version at
>> all).
>>
>> IMO, a lot of 3rd party components *do* work very well - guys at
>> Developer Express, ComponentOne, Infragistic etc. really produce very
>> usable products. Serious developer should at least try them before judge
>> about their usability or quality. They are also very cheap comparing to
>> the price of developing only few percent of their features. Maybe it
>> sounds like advertising but I really just buy them and use them, and I
>> want to share good experience with other developers.
>>
>>
>> Regards,
>> Thomas
>>
>> -----------------------------------------
>> NConstruct - Intelligent Software Factory
>> http://www.nconstruct.com
>> -----------------------------------------
>>
>>
>>
>>
>> Baz wrote:
>>> Well I haven't got VS 2005 and I'm not likely to get it either (having
>>> wasted a significant amount of my own money on upgrading from VS 6 to VS
>>> 2002/2003, and then concluding that it sucked so badly that I was simply
> not
>>> interested in using it).
>>>
>>> Nor am I impressed by a product which requires me to buy third-party
> add-ons
>>> in order for it to be anywhere near usable.
>>>
>>>
>>> "Thomas" <thomas@nconstruct.com> wrote in message
>>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>>> Baz wrote:
>>>>> I have two things to say to you: linked subforms and continuous forms.
>>>> Baz, I don't think this is an Access advantage. For example, look at
>>>> those tutorials:
>>>>
> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>> It's fast to create (at least as fast as Access), it has more features
>>>> than Access etc.
>>>>
>>>> This is only one approach - it's similar to Access' one (I don't like
>>>> any of them, though). If you need n-tiered application it's better to
> do
>>>> the dynamic grid creation. In both cases you can do it with VS out of
>>>> the box or you can buy some 3rd party components.
>>>>
>>>> -- 
>>>>
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>> -----------------------------------------
>>>> NConstruct - Intelligent Software Factory
>>>> http://www.nconstruct.com
>>>> -----------------------------------------
>>>>
>>>
> 
> 
0
Thomas
6/6/2007 3:25:13 PM
:-)
OK, I can partly agree with you as I prefer the bike, too. Maybe it's 
really bad analogy. What about this one (note the "Compared with the 
scroll..." sentence):
http://www.youtube.com/watch?v=xFAWR6hzZek

;-)


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
>> (it's easier to ride bike than drive car, too).
> 
> Bad argument to make for me; I'm nearing 40, and I've never driven a car.  I 
> use public transit for everything.  About half my friends don't drive, 
> either, and my partner, who's a professional photographer, uses his bike as 
> his company vehicle without a problem.
> 
>> As you say, form or report creating wizards are not of much use.
> 
> Actually, it wasn't me that said that, though for the most part, I agree. :)
> 
> 
> 
> Rob 
> 
> 
0
Thomas
6/6/2007 3:35:50 PM
I also think it's not good to use VS/.NET to port your existing 
applications but it should be considered when thinking about the new ones.

But you can't argument advantages of one development tool just with 
saying that it is better for certain people.

I have a proposal for trying to solve this dilemma: if you have one or 
two days in the following month or two, we can imagine simple fictitious 
business application (it can be also some usable problem which we can 
sell then as a product, too :-)).
You can propose the half of virtual customer's demands, and I will 
propose the other half. We can make together a portable database model 
which will be the starting point for both of us. You will use Access 
while I'll use VS/.NET to build the business application. When both of 
us would be ready we can show the movie how did we build the application 
and exchange application installer file.
We can use any additional tool and we'll compare the price of all used 
tools (including Access and VS). The purpose of this "competition" is to 
show both the speed of development and costs of software used. I think 
this could be a good test for anyone watching this debate and asking 
himself if it's worth to stick with .NET or rather with Access.
What do you think about it?

Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
> I think what Larry and I are trying to say is that for us, we find Access to 
> vastly outperform .NET in terms of development time.
> 
> That said, however, it's possible that .NET 2005 can do it, but I, at least, 
> haven't seen anything to prove that to me concretely, and I'm certainly not 
> about to spend money, and months or years worth of time porting my existing 
> business apps in the hopes that their might be some marginal gain to my 
> ability to develop applications faster.  Even if we accept that development 
> is faster, the additional time/learning curve required easily outweighs any 
> advantage to .NET.
> 
> The performance of VB.NET also has yet to equal that of VB6/VBA, so that is 
> a consideration as well.  The only way to get acceptable performance in many 
> cases is to use unmanaged code, and I have no ambitions to learn C++.
> 
> 
> Rob
> 
> "Thomas" <thomas@nconstruct.com> wrote in message 
> news:OU4ZcmBqHHA.4152@TK2MSFTNGP04.phx.gbl...
>> Larry Linson wrote:
>>> "Thomas" <thomas@nconstruct.com> wrote
>>>
>>>   > . . .
>>>   > I think development was faster with Access only in the early age of
>>>   > .NET. With .NET you have much greater possibilities to gradually
>>>   > accumulate really reusable pieces of code or create automated code
>>>   > generation tools which significantly outperform Access in almost any 
>>> aspect.
>>>
>>> Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, 
>>> made friends in Redmond with that kind of reply.
>>>
>>> I had a C-programmer colleague back at the "major computer manufacturer" 
>>> from which I retired who said something similar about C, and then about 
>>> C++, comparing it to PL/I, Basic, and then to Visual Basic and Access. 
>>> He's likely saying the same about C#, now, but chances are the clients 
>>> who can afford him are all doing distributed enterprise apps that are 
>>> web-based.
>>>
>>> The problem is that you _DO NEED_ to "gradually accumulate" (and 
>>> purchase/license -- lots of purchasing/licensing going on in the DotNet 
>>> world) reusable pieces of code or create automated code generation tools 
>>> in order to do with any facility even the most basic of the database 
>>> functions that are built in to Access, right out of the box. That is, if 
>>> you re-create Access in DotNet, you'll almost catch up with "the real 
>>> thing."
>>>
>>> You do realize, don't you, that the statement "significantly outperform 
>>> Access in almost any aspect" is essentially content-free, don't you? 
>>> Frankly, my view is that "Access out of the box outperforms Visual Studio 
>>> in creating normal business database applications for the single-user, 
>>> multi-user, anc client-server environments". I know a few people who do 
>>> both Access and DotNet, and they agree with me; the ones who don't are 
>>> those who don't now use, or perhaps never have used, Access and think 
>>> it's just a "junior version" of DotNet.
>>>
>>> The essential functionality needed for controlling the application, 
>>> navigating, and manipulating the database is ALREADY THERE with Access, 
>>> so all you have to do is put in the business functions (and, unless you 
>>> develop very similar applications for multiple businesses, it's not going 
>>> to be useful, and depending on your agreement with your clients, may not 
>>> be legal, to "package" their business functionality as "really reusable 
>>> pieces of code".)
>>>
>>> I spent some of the early part of my career creating development tools. 
>>> It's interesting work, but it's not something an application developer 
>>> should have to do in order to get decent development for their investment 
>>> of time and effort, or to be able to accomplish what they need at all. 
>>> It's a lot more productive for the application developer to develop 
>>> applications, not tools, not create and accumulate libraries.
>>>
>>>  Larry Linson
>>>  Microsoft Access MVP
>>>
>>>
>>>
>> Larry, don't get me wrong. It's really not about being a DotNet fan (and I 
>> believe you can get friends in Redmond speaking friendly about Access, 
>> too). :-)
>>
>> I do work right now (and was working for several years in the past) both 
>> with Access and .NET, and I'm just comparing both of the worlds.
>>
>> Speaking about the licensing "problem" - I think we should calculate if 
>> this is really the drawback of the .NET. Most of the components typical 
>> developer needs are royalty free so you have to purchase only one piece of 
>> the license. For example, if you need rich gui components you will spend 
>> about $1000 but you will get very powerful tools which can significantly 
>> shorten development time - for both Windows and Web platform (not to 
>> mention enormous end-user capabilities). The same (or even cheaper) is 
>> with the refactoring or code generation tools etc. Comparing such sums 
>> with the earnings of developer (or company) is insignificant.
>>
>> So, the question should not be if Access out of the box outperforms Visual 
>> Studio (also out of the box) for some type of applications. I agree it is 
>> probably true if we treat this question only theoretically but in the real 
>> world developer should calculate the whole costs of development. In the 
>> end everybody (at least in my opinion) realize that the only meaningful 
>> cost is the development time.
>>
>> Therefore I see the only reasonable argument in behalf of Access the 
>> learning curve. Someone should consider if it's worth to spend more time 
>> learning .NET and OO programming, and get the chance to compete also in 
>> the enterprise applications market, or spend less time and stay limited 
>> with the Access capabilities and obsolete programming language.
>>
>>
>> -- 
>>
>>
>> Regards,
>> Thomas
>>
>> -----------------------------------------
>> NConstruct - Intelligent Software Factory
>> http://www.nconstruct.com
>> -----------------------------------------
>>
> 
> 
0
Thomas
6/6/2007 4:10:10 PM
The biggest example that comes to mind is the ability to create 
"mini-forms".  For example, I have a continuous subform for comments that 
has a delete button on it, a few check boxes, and so forth.  It's about a 1" 
high form with a multi-line text box embedded within it.  While in this 
case, it's a plain text box, I have the option to make it an RTF editor or 
anything else I might want.  I'd seriously like to see a grid view that can 
handle that kind of form design within it.  Nothing even comes close that 
I've ever seen.  What's more, to do that kind of design work, I don't need 
any additional knowledge of the control; my ability to create forms is all I 
need to know.

But even looking at a one-line, grid style of form, there's all the 
associated form events to consider, which most grids don't support, the 
ability to put custom controls, images, command buttons, etc., into your 
grid, the ability to disable fields (though some grids may do better in this 
regard, since Access can only enable/disable the entire column at a 
time...few grids support selective disabling, though, that I've seen).

It's these sorts of things that make me look at things like data grids as 
the lesser form of continuous forms.  And the ability to embed one form 
within another is just as nice.  I think you can get the same effect 
with...was it panes they called it in .NET?...or using visual inheritance, 
but I don't remember it being as easy as dragging and dropping one form on 
top of another.  I never really got that advanced on .NET, so I'd be content 
to have it proven that it's just as easy in .NET as it is in Access.



Rob

"Thomas" <thomas@nconstruct.com> wrote in message 
news:uD2EW1EqHHA.4872@TK2MSFTNGP03.phx.gbl...
> I'd like to hear some examples where continuous forms outperforms .NET 
> grids?
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
>
>
>
>
> Robert Morley wrote:
>> You SERIOUSLY haven't looked at continuous forms and subforms if you 
>> think any type of grid control holds a candle to them.
>>
>>
>> Rob
>>
>> "Thomas" <thomas@nconstruct.com> wrote in message 
>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>> Baz wrote:
>>>> I have two things to say to you: linked subforms and continuous forms.
>>> Baz, I don't think this is an Access advantage. For example, look at 
>>> those tutorials:
>>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>
>>> It's fast to create (at least as fast as Access), it has more features 
>>> than Access etc.
>>>
>>> This is only one approach - it's similar to Access' one (I don't like 
>>> any of them, though). If you need n-tiered application it's better to do 
>>> the dynamic grid creation. In both cases you can do it with VS out of 
>>> the box or you can buy some 3rd party components.
>>>
>>> -- 
>>>
>>>
>>> Regards,
>>> Thomas
>>>
>>> -----------------------------------------
>>> NConstruct - Intelligent Software Factory
>>> http://www.nconstruct.com
>>> -----------------------------------------
>>>
>> 

0
Robert
6/6/2007 4:20:58 PM
It's an interesting idea, but I seriously don't have the time these days. 
If you'd asked me over the winter, I might've been able to do it.  If 
anybody else takes you up on that, though, I'd love to see the results.


Rob

"Thomas" <thomas@nconstruct.com> wrote in message 
news:uDt%23tUFqHHA.2652@TK2MSFTNGP02.phx.gbl...
>I also think it's not good to use VS/.NET to port your existing 
>applications but it should be considered when thinking about the new ones.
>
> But you can't argument advantages of one development tool just with saying 
> that it is better for certain people.
>
> I have a proposal for trying to solve this dilemma: if you have one or two 
> days in the following month or two, we can imagine simple fictitious 
> business application (it can be also some usable problem which we can sell 
> then as a product, too :-)).
> You can propose the half of virtual customer's demands, and I will propose 
> the other half. We can make together a portable database model which will 
> be the starting point for both of us. You will use Access while I'll use 
> VS/.NET to build the business application. When both of us would be ready 
> we can show the movie how did we build the application and exchange 
> application installer file.
> We can use any additional tool and we'll compare the price of all used 
> tools (including Access and VS). The purpose of this "competition" is to 
> show both the speed of development and costs of software used. I think 
> this could be a good test for anyone watching this debate and asking 
> himself if it's worth to stick with .NET or rather with Access.
> What do you think about it?
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
>
>
>
>
> Robert Morley wrote:
>> I think what Larry and I are trying to say is that for us, we find Access 
>> to vastly outperform .NET in terms of development time.
>>
>> That said, however, it's possible that .NET 2005 can do it, but I, at 
>> least, haven't seen anything to prove that to me concretely, and I'm 
>> certainly not about to spend money, and months or years worth of time 
>> porting my existing business apps in the hopes that their might be some 
>> marginal gain to my ability to develop applications faster.  Even if we 
>> accept that development is faster, the additional time/learning curve 
>> required easily outweighs any advantage to .NET.
>>
>> The performance of VB.NET also has yet to equal that of VB6/VBA, so that 
>> is a consideration as well.  The only way to get acceptable performance 
>> in many cases is to use unmanaged code, and I have no ambitions to learn 
>> C++.
>>
>>
>> Rob
>>
>> "Thomas" <thomas@nconstruct.com> wrote in message 
>> news:OU4ZcmBqHHA.4152@TK2MSFTNGP04.phx.gbl...
>>> Larry Linson wrote:
>>>> "Thomas" <thomas@nconstruct.com> wrote
>>>>
>>>>   > . . .
>>>>   > I think development was faster with Access only in the early age of
>>>>   > .NET. With .NET you have much greater possibilities to gradually
>>>>   > accumulate really reusable pieces of code or create automated code
>>>>   > generation tools which significantly outperform Access in almost 
>>>> any aspect.
>>>>
>>>> Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, 
>>>> made friends in Redmond with that kind of reply.
>>>>
>>>> I had a C-programmer colleague back at the "major computer 
>>>> manufacturer" from which I retired who said something similar about C, 
>>>> and then about C++, comparing it to PL/I, Basic, and then to Visual 
>>>> Basic and Access. He's likely saying the same about C#, now, but 
>>>> chances are the clients who can afford him are all doing distributed 
>>>> enterprise apps that are web-based.
>>>>
>>>> The problem is that you _DO NEED_ to "gradually accumulate" (and 
>>>> purchase/license -- lots of purchasing/licensing going on in the DotNet 
>>>> world) reusable pieces of code or create automated code generation 
>>>> tools in order to do with any facility even the most basic of the 
>>>> database functions that are built in to Access, right out of the box. 
>>>> That is, if you re-create Access in DotNet, you'll almost catch up with 
>>>> "the real thing."
>>>>
>>>> You do realize, don't you, that the statement "significantly outperform 
>>>> Access in almost any aspect" is essentially content-free, don't you? 
>>>> Frankly, my view is that "Access out of the box outperforms Visual 
>>>> Studio in creating normal business database applications for the 
>>>> single-user, multi-user, anc client-server environments". I know a few 
>>>> people who do both Access and DotNet, and they agree with me; the ones 
>>>> who don't are those who don't now use, or perhaps never have used, 
>>>> Access and think it's just a "junior version" of DotNet.
>>>>
>>>> The essential functionality needed for controlling the application, 
>>>> navigating, and manipulating the database is ALREADY THERE with Access, 
>>>> so all you have to do is put in the business functions (and, unless you 
>>>> develop very similar applications for multiple businesses, it's not 
>>>> going to be useful, and depending on your agreement with your clients, 
>>>> may not be legal, to "package" their business functionality as "really 
>>>> reusable pieces of code".)
>>>>
>>>> I spent some of the early part of my career creating development tools. 
>>>> It's interesting work, but it's not something an application developer 
>>>> should have to do in order to get decent development for their 
>>>> investment of time and effort, or to be able to accomplish what they 
>>>> need at all. It's a lot more productive for the application developer 
>>>> to develop applications, not tools, not create and accumulate 
>>>> libraries.
>>>>
>>>>  Larry Linson
>>>>  Microsoft Access MVP
>>>>
>>>>
>>>>
>>> Larry, don't get me wrong. It's really not about being a DotNet fan (and 
>>> I believe you can get friends in Redmond speaking friendly about Access, 
>>> too). :-)
>>>
>>> I do work right now (and was working for several years in the past) both 
>>> with Access and .NET, and I'm just comparing both of the worlds.
>>>
>>> Speaking about the licensing "problem" - I think we should calculate if 
>>> this is really the drawback of the .NET. Most of the components typical 
>>> developer needs are royalty free so you have to purchase only one piece 
>>> of the license. For example, if you need rich gui components you will 
>>> spend about $1000 but you will get very powerful tools which can 
>>> significantly shorten development time - for both Windows and Web 
>>> platform (not to mention enormous end-user capabilities). The same (or 
>>> even cheaper) is with the refactoring or code generation tools etc. 
>>> Comparing such sums with the earnings of developer (or company) is 
>>> insignificant.
>>>
>>> So, the question should not be if Access out of the box outperforms 
>>> Visual Studio (also out of the box) for some type of applications. I 
>>> agree it is probably true if we treat this question only theoretically 
>>> but in the real world developer should calculate the whole costs of 
>>> development. In the end everybody (at least in my opinion) realize that 
>>> the only meaningful cost is the development time.
>>>
>>> Therefore I see the only reasonable argument in behalf of Access the 
>>> learning curve. Someone should consider if it's worth to spend more time 
>>> learning .NET and OO programming, and get the chance to compete also in 
>>> the enterprise applications market, or spend less time and stay limited 
>>> with the Access capabilities and obsolete programming language.
>>>
>>>
>>> -- 
>>>
>>>
>>> Regards,
>>> Thomas
>>>
>>> -----------------------------------------
>>> NConstruct - Intelligent Software Factory
>>> http://www.nconstruct.com
>>> -----------------------------------------
>>>
>> 

0
Robert
6/6/2007 4:22:57 PM
Rob, great, winter is quite suitable if nobody else would have time 
before that.


Regards,
Thomas

-----------------------------------------
NConstruct - Intelligent Software Factory
http://www.nconstruct.com
-----------------------------------------




Robert Morley wrote:
> It's an interesting idea, but I seriously don't have the time these days. 
> If you'd asked me over the winter, I might've been able to do it.  If 
> anybody else takes you up on that, though, I'd love to see the results.
> 
> 
> Rob
> 
> "Thomas" <thomas@nconstruct.com> wrote in message 
> news:uDt%23tUFqHHA.2652@TK2MSFTNGP02.phx.gbl...
>> I also think it's not good to use VS/.NET to port your existing 
>> applications but it should be considered when thinking about the new ones.
>>
>> But you can't argument advantages of one development tool just with saying 
>> that it is better for certain people.
>>
>> I have a proposal for trying to solve this dilemma: if you have one or two 
>> days in the following month or two, we can imagine simple fictitious 
>> business application (it can be also some usable problem which we can sell 
>> then as a product, too :-)).
>> You can propose the half of virtual customer's demands, and I will propose 
>> the other half. We can make together a portable database model which will 
>> be the starting point for both of us. You will use Access while I'll use 
>> VS/.NET to build the business application. When both of us would be ready 
>> we can show the movie how did we build the application and exchange 
>> application installer file.
>> We can use any additional tool and we'll compare the price of all used 
>> tools (including Access and VS). The purpose of this "competition" is to 
>> show both the speed of development and costs of software used. I think 
>> this could be a good test for anyone watching this debate and asking 
>> himself if it's worth to stick with .NET or rather with Access.
>> What do you think about it?
>>
>> Regards,
>> Thomas
>>
>> -----------------------------------------
>> NConstruct - Intelligent Software Factory
>> http://www.nconstruct.com
>> -----------------------------------------
>>
>>
>>
>>
>> Robert Morley wrote:
>>> I think what Larry and I are trying to say is that for us, we find Access 
>>> to vastly outperform .NET in terms of development time.
>>>
>>> That said, however, it's possible that .NET 2005 can do it, but I, at 
>>> least, haven't seen anything to prove that to me concretely, and I'm 
>>> certainly not about to spend money, and months or years worth of time 
>>> porting my existing business apps in the hopes that their might be some 
>>> marginal gain to my ability to develop applications faster.  Even if we 
>>> accept that development is faster, the additional time/learning curve 
>>> required easily outweighs any advantage to .NET.
>>>
>>> The performance of VB.NET also has yet to equal that of VB6/VBA, so that 
>>> is a consideration as well.  The only way to get acceptable performance 
>>> in many cases is to use unmanaged code, and I have no ambitions to learn 
>>> C++.
>>>
>>>
>>> Rob
>>>
>>> "Thomas" <thomas@nconstruct.com> wrote in message 
>>> news:OU4ZcmBqHHA.4152@TK2MSFTNGP04.phx.gbl...
>>>> Larry Linson wrote:
>>>>> "Thomas" <thomas@nconstruct.com> wrote
>>>>>
>>>>>   > . . .
>>>>>   > I think development was faster with Access only in the early age of
>>>>>   > .NET. With .NET you have much greater possibilities to gradually
>>>>>   > accumulate really reusable pieces of code or create automated code
>>>>>   > generation tools which significantly outperform Access in almost 
>>>>> any aspect.
>>>>>
>>>>> Ah, Thomas, you said that like a true DotNet bigot. You have, no doubt, 
>>>>> made friends in Redmond with that kind of reply.
>>>>>
>>>>> I had a C-programmer colleague back at the "major computer 
>>>>> manufacturer" from which I retired who said something similar about C, 
>>>>> and then about C++, comparing it to PL/I, Basic, and then to Visual 
>>>>> Basic and Access. He's likely saying the same about C#, now, but 
>>>>> chances are the clients who can afford him are all doing distributed 
>>>>> enterprise apps that are web-based.
>>>>>
>>>>> The problem is that you _DO NEED_ to "gradually accumulate" (and 
>>>>> purchase/license -- lots of purchasing/licensing going on in the DotNet 
>>>>> world) reusable pieces of code or create automated code generation 
>>>>> tools in order to do with any facility even the most basic of the 
>>>>> database functions that are built in to Access, right out of the box. 
>>>>> That is, if you re-create Access in DotNet, you'll almost catch up with 
>>>>> "the real thing."
>>>>>
>>>>> You do realize, don't you, that the statement "significantly outperform 
>>>>> Access in almost any aspect" is essentially content-free, don't you? 
>>>>> Frankly, my view is that "Access out of the box outperforms Visual 
>>>>> Studio in creating normal business database applications for the 
>>>>> single-user, multi-user, anc client-server environments". I know a few 
>>>>> people who do both Access and DotNet, and they agree with me; the ones 
>>>>> who don't are those who don't now use, or perhaps never have used, 
>>>>> Access and think it's just a "junior version" of DotNet.
>>>>>
>>>>> The essential functionality needed for controlling the application, 
>>>>> navigating, and manipulating the database is ALREADY THERE with Access, 
>>>>> so all you have to do is put in the business functions (and, unless you 
>>>>> develop very similar applications for multiple businesses, it's not 
>>>>> going to be useful, and depending on your agreement with your clients, 
>>>>> may not be legal, to "package" their business functionality as "really 
>>>>> reusable pieces of code".)
>>>>>
>>>>> I spent some of the early part of my career creating development tools. 
>>>>> It's interesting work, but it's not something an application developer 
>>>>> should have to do in order to get decent development for their 
>>>>> investment of time and effort, or to be able to accomplish what they 
>>>>> need at all. It's a lot more productive for the application developer 
>>>>> to develop applications, not tools, not create and accumulate 
>>>>> libraries.
>>>>>
>>>>>  Larry Linson
>>>>>  Microsoft Access MVP
>>>>>
>>>>>
>>>>>
>>>> Larry, don't get me wrong. It's really not about being a DotNet fan (and 
>>>> I believe you can get friends in Redmond speaking friendly about Access, 
>>>> too). :-)
>>>>
>>>> I do work right now (and was working for several years in the past) both 
>>>> with Access and .NET, and I'm just comparing both of the worlds.
>>>>
>>>> Speaking about the licensing "problem" - I think we should calculate if 
>>>> this is really the drawback of the .NET. Most of the components typical 
>>>> developer needs are royalty free so you have to purchase only one piece 
>>>> of the license. For example, if you need rich gui components you will 
>>>> spend about $1000 but you will get very powerful tools which can 
>>>> significantly shorten development time - for both Windows and Web 
>>>> platform (not to mention enormous end-user capabilities). The same (or 
>>>> even cheaper) is with the refactoring or code generation tools etc. 
>>>> Comparing such sums with the earnings of developer (or company) is 
>>>> insignificant.
>>>>
>>>> So, the question should not be if Access out of the box outperforms 
>>>> Visual Studio (also out of the box) for some type of applications. I 
>>>> agree it is probably true if we treat this question only theoretically 
>>>> but in the real world developer should calculate the whole costs of 
>>>> development. In the end everybody (at least in my opinion) realize that 
>>>> the only meaningful cost is the development time.
>>>>
>>>> Therefore I see the only reasonable argument in behalf of Access the 
>>>> learning curve. Someone should consider if it's worth to spend more time 
>>>> learning .NET and OO programming, and get the chance to compete also in 
>>>> the enterprise applications market, or spend less time and stay limited 
>>>> with the Access capabilities and obsolete programming language.
>>>>
>>>>
>>>> -- 
>>>>
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>> -----------------------------------------
>>>> NConstruct - Intelligent Software Factory
>>>> http://www.nconstruct.com
>>>> -----------------------------------------
>>>>
> 
0
Thomas
6/6/2007 4:41:30 PM
Thomas <thomas@nconstruct.com> wrote:

>I have a proposal for trying to solve this dilemma: if you have one or 
>two days in the following month or two, we can imagine simple fictitious 
>business application (it can be also some usable problem which we can 
>sell then as a product, too :-)).

Or how about for a non profit group that has a geniune need for such a solution.

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.granite.ab.ca/accsmstr.htm
   Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
0
Tony
6/6/2007 6:53:42 PM
A simple question has been posed - does it make sense to move from MS Access 
to .NET?

Back in 1999, I rewrote an application for the third time.  The first 
version was in DBase II and the second version was in Progress. The plan for 
version 3 was VB on the frontend and Sybase SQL Anywhere on the backend. 
With 10% of the project completed, I was through 25% of the money - $10,000 
at this point.  (Math quiz: what was the budget and what was the projected 
cost overrun?)

Two questions had to be answered. 1) How did I screw up the budget so 
terribly and 2) how could I fix it?

The answer to (1) is that I budgeted the project based on what I could do it 
in MS Access.  The reason that I didn't use Access is that for multi-user 
applications using bound forms and linked tables across the network, Access 
stinks. It is slow and unreliable.

So what to do, what to do?  The obvious question was to fix the data 
marshalling in MS Access so that it is fast and reliable.
Did that.  My Access applications now run 125 times faster on the network 
with bound forms to linked tables.  Starting over with Access on the 
frontend and Sybase on the backend , the total project cost (including the 
initial $10,000) came in at $44,000.  Speed over the network is 
instantaneous and it has never broken.

So why the shift to .NET?  1) My Access middleware DLL is written in VB and 
utilizes RDO both of which are nearing the end of life. 2) My middleware 
only works with Sybase, though with some work, it could be made to work with 
SQL Server.  3) Access looks old.  4) Microsoft is pushing .NET.

The project I'm now finishing up uses .NET, C# and SQL Server.  The budget 
was set at 1.3 times a comparable Access project.  It appears that the final 
cost will come in at budget.

The pluses: The database is in New Jersey with the frontend up here in 
Maine.  Performance is unbelievably fast - you wouldn't know the database 
was off site over a wide area network.  It doesn't break. It looks great. 
Plus, the project is coming in on budget.

The minuses:
  - Long learning curve.
  - Out-of-the-box doesn't cut it - I use the Developer Express controls 
(fantastic).
  - The data designers are pretty much useless for the sql logic - wrote my 
own which work.
  - There are some nasty gotchas in ADO.NET requiring work-a-rounds.
  - VS 2005 is just plain painful to design forms - dropping, renaming and 
binding controls is way too slow.
  - Microsoft is tardy in getting service packs out to fix framework bugs.

So back to the initial question, "does it make sense to move from MS Access 
to .NET?"  Even with some of the crap in Visual Studio, the outcome is 
positive and well worth the investment.

My clients love the results which means business will be good for some time. 
New product development to replace aging Access is proving to be a smart 
move.



0
Jim
6/6/2007 7:06:37 PM
This only tell us that you have started a project in VB without knowing VB. 
I never saw someone starting a project with a technology that he (/her/them) 
doesn't know without going into massive cost overruns.

As to the data marshalling that you have done, I would be very surprised if 
you can't do the same thing with either VB or .NET.  In fact, I would be 
even more surprised if you can't do any better with NET than you did with 
Access.

NET has been designed to give you the fastest response as possible with 
every kind of backend (JET, SQL-Server, Oracle, heterogeneous, etc.) over 
any network (Local, LAN, WAN) as possible.  If you make a test that gives a 
slower response with .NET than with anything else, it's not because NET is 
slower, it's because you have made one or more errors somewhere.

Don't forget that with practically any kind of new technology, you will 
usually need at least one year of experience to have some mastery of it.

-- 
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Jim Rand" <jimrand@ix.netcom.com> wrote in message 
news:uUU%23Q3GqHHA.3368@TK2MSFTNGP02.phx.gbl...
>A simple question has been posed - does it make sense to move from MS 
>Access to .NET?
>
> Back in 1999, I rewrote an application for the third time.  The first 
> version was in DBase II and the second version was in Progress. The plan 
> for version 3 was VB on the frontend and Sybase SQL Anywhere on the 
> backend. With 10% of the project completed, I was through 25% of the 
> money - $10,000 at this point.  (Math quiz: what was the budget and what 
> was the projected cost overrun?)
>
> Two questions had to be answered. 1) How did I screw up the budget so 
> terribly and 2) how could I fix it?
>
> The answer to (1) is that I budgeted the project based on what I could do 
> it in MS Access.  The reason that I didn't use Access is that for 
> multi-user applications using bound forms and linked tables across the 
> network, Access stinks. It is slow and unreliable.
>
> So what to do, what to do?  The obvious question was to fix the data 
> marshalling in MS Access so that it is fast and reliable.
> Did that.  My Access applications now run 125 times faster on the network 
> with bound forms to linked tables.  Starting over with Access on the 
> frontend and Sybase on the backend , the total project cost (including the 
> initial $10,000) came in at $44,000.  Speed over the network is 
> instantaneous and it has never broken.
>
> So why the shift to .NET?  1) My Access middleware DLL is written in VB 
> and utilizes RDO both of which are nearing the end of life. 2) My 
> middleware only works with Sybase, though with some work, it could be made 
> to work with SQL Server.  3) Access looks old.  4) Microsoft is pushing 
> .NET.
>
> The project I'm now finishing up uses .NET, C# and SQL Server.  The budget 
> was set at 1.3 times a comparable Access project.  It appears that the 
> final cost will come in at budget.
>
> The pluses: The database is in New Jersey with the frontend up here in 
> Maine.  Performance is unbelievably fast - you wouldn't know the database 
> was off site over a wide area network.  It doesn't break. It looks great. 
> Plus, the project is coming in on budget.
>
> The minuses:
>  - Long learning curve.
>  - Out-of-the-box doesn't cut it - I use the Developer Express controls 
> (fantastic).
>  - The data designers are pretty much useless for the sql logic - wrote my 
> own which work.
>  - There are some nasty gotchas in ADO.NET requiring work-a-rounds.
>  - VS 2005 is just plain painful to design forms - dropping, renaming and 
> binding controls is way too slow.
>  - Microsoft is tardy in getting service packs out to fix framework bugs.
>
> So back to the initial question, "does it make sense to move from MS 
> Access to .NET?"  Even with some of the crap in Visual Studio, the outcome 
> is positive and well worth the investment.
>
> My clients love the results which means business will be good for some 
> time. New product development to replace aging Access is proving to be a 
> smart move.
>
>
> 


0
Sylvain
6/6/2007 7:26:50 PM
"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
wrote in message news:OxP2LDHqHHA.4608@TK2MSFTNGP02.phx.gbl...
> This only tell us that you have started a project in VB without knowing 
> VB. I never saw someone starting a project with a technology that he 
> (/her/them) doesn't know without going into massive cost overruns.

The VB6 databinding killed me.  .NET databinding is so much better and 
explains why the project costs for Access and .NET are in the same ballpark. 
My experience parallels others - VB 6 takes about 3 to 5 times longer to 
write compared to Access.  .NET is coming in at 1.3 times which, when you 
look at the other benefits, is very acceptable.

> As to the data marshalling that you have done, I would be very surprised 
> if you can't do the same thing with either VB or .NET.  In fact, I would 
> be even more surprised if you can't do any better with NET than you did 
> with Access.

ADO.NET disconnected datasets mirrors my 1999 Access/VB RDO architecture 
with the Fill and Update methods.  That's one of the reasons I'm so 
comfortable working with ADO.NET.

>
> NET has been designed to give you the fastest response as possible with 
> every kind of backend (JET, SQL-Server, Oracle, heterogeneous, etc.) over 
> any network (Local, LAN, WAN) as possible.  If you make a test that gives 
> a slower response with .NET than with anything else, it's not because NET 
> is slower, it's because you have made one or more errors somewhere.

Couldn't agree with you more.  With multi-threading, you can give the 
illusion of even faster speed.

>
> Don't forget that with practically any kind of new technology, you will 
> usually need at least one year of experience to have some mastery of it.
>

Plan on at least a year.  But as I say,  replacing aging Access with .NET 
has turned out be a smart business move. 


0
Jim
6/6/2007 8:14:09 PM
Per Robert Morley:
>The performance of VB.NET also has yet to equal that of VB6/VBA, so that is 
>a consideration as well.  The only way to get acceptable performance 

But isn't perceived performance mainly how fast the app can get
stuff in and out of the back end?   Given that, wouldn't they all
be about the same?
-- 
PeteCresswell
0
PeteCresswell
6/6/2007 11:13:50 PM
Per Jim Rand:
>So what to do, what to do?  The obvious question was to fix the data 
>marshalling in MS Access so that it is fast and reliable.
>Did that.  My Access applications now run 125 times faster on the network 
>with bound forms to linked tables. 

Can you list some of the things you did to make that improvement
in marshalling?
-- 
PeteCresswell
0
PeteCresswell
6/6/2007 11:16:44 PM
So you budgeted to do a project in Access and then you tried to do it in VB
for the same budget (duh!), and because you couldn't this is somehow Access'
fault?

Access using bound forms and linked tables for multi-user apps is so slow
and unreliable that I am always getting panic-stricken support calls from my
many customers.  Some of them I hear from every year!  Mind you, I do use
SQL Server, not Sybase.

I think your post tells us a lot more about you than it does about any
technologies.

"Jim Rand" <jimrand@ix.netcom.com> wrote in message
news:uUU%23Q3GqHHA.3368@TK2MSFTNGP02.phx.gbl...
> A simple question has been posed - does it make sense to move from MS
Access
> to .NET?
>
> Back in 1999, I rewrote an application for the third time.  The first
> version was in DBase II and the second version was in Progress. The plan
for
> version 3 was VB on the frontend and Sybase SQL Anywhere on the backend.
> With 10% of the project completed, I was through 25% of the money -
$10,000
> at this point.  (Math quiz: what was the budget and what was the projected
> cost overrun?)
>
> Two questions had to be answered. 1) How did I screw up the budget so
> terribly and 2) how could I fix it?
>
> The answer to (1) is that I budgeted the project based on what I could do
it
> in MS Access.  The reason that I didn't use Access is that for multi-user
> applications using bound forms and linked tables across the network,
Access
> stinks. It is slow and unreliable.
>
<snip>


0
Baz
6/7/2007 4:54:16 AM
Where do I start?  How about the bloated, festering dotnet framework,
redolent as it is with the promise of versioning nightmares in years ahead?
How about not being able to write unmanaged code in anything but C++?  How
about it being so damned slow?  How about the IDE being so damned awful?
How about MS's sheer, arrogant supidity in trying to kill the world's most
popular development tool (I refer of course to VB6) without even providing
backward compatibility?

That's a few gripes about the big stuff, I could think of a lot more if I
tried.  There's LOADS more stuff at the small level, my favourite in
2002/2003 was the godawful combo box which couldn't even do what a VB6 combo
could do, let alone an Access combo.  Sure, you can build your own controls,
which is exactly what I did to get a half-decent combo box (or you can buy
'em if you didn't already think you'd wasted enough dosh on this garbage),
but that's what you have to do all the time: so much of it doesn't quite
work as you would expect or want that you spend all your damn time
finding/creating workarounds and alternatives.

Yeeeuk!  I don't blame you for puffing this stuff - you've got a living to
make - but frankly it makes me ill.

"Thomas" <thomas@nconstruct.com> wrote in message
news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
> I still don't know the reasons you were not satisfied with VS/.NET
> (except that with learning time)?
>
>
> Regards,
> Thomas
>
> -----------------------------------------
> NConstruct - Intelligent Software Factory
> http://www.nconstruct.com
> -----------------------------------------
>
>
>
>
> Baz wrote:
> > Yep, that sounds like advertising.  As I said, I own VS 2003
Professional
> > and I consider it to have been a complete waste of money.  I do not
believe
> > that VS 2005 can be so much better that it is worth me spending any time
on
> > it, and I'm certainly not going to waste any money buying add-ons for
it.
> > I'd rather put my efforts into continuing my investigations into Delphi
(not
> > that I see Delphi as a serious contender to Access either for database
> > applications, it's just that, for the odd occasion when I do something
for
> > which I don't consider Access suitable, I'd like to have a serious and
> > current alternative to VB6).
> >
> > "Thomas" <thomas@nconstruct.com> wrote in message
> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
> >> component if you don't want, and you can still produce i.e. continuous
> >> forms with DataGridView component. This is not the best solution but
> >> either is not worse than Access (for which there is no free version at
> >> all).
> >>
> >> IMO, a lot of 3rd party components *do* work very well - guys at
> >> Developer Express, ComponentOne, Infragistic etc. really produce very
> >> usable products. Serious developer should at least try them before
judge
> >> about their usability or quality. They are also very cheap comparing to
> >> the price of developing only few percent of their features. Maybe it
> >> sounds like advertising but I really just buy them and use them, and I
> >> want to share good experience with other developers.
> >>
> >>
> >> Regards,
> >> Thomas
> >>
> >> -----------------------------------------
> >> NConstruct - Intelligent Software Factory
> >> http://www.nconstruct.com
> >> -----------------------------------------
> >>
> >>
> >>
> >>
> >> Baz wrote:
> >>> Well I haven't got VS 2005 and I'm not likely to get it either (having
> >>> wasted a significant amount of my own money on upgrading from VS 6 to
VS
> >>> 2002/2003, and then concluding that it sucked so badly that I was
simply
> > not
> >>> interested in using it).
> >>>
> >>> Nor am I impressed by a product which requires me to buy third-party
> > add-ons
> >>> in order for it to be anywhere near usable.
> >>>
> >>>
> >>> "Thomas" <thomas@nconstruct.com> wrote in message
> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
> >>>> Baz wrote:
> >>>>> I have two things to say to you: linked subforms and continuous
forms.
> >>>> Baz, I don't think this is an Access advantage. For example, look at
> >>>> those tutorials:
> >>>>
> >
http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
> >
http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
> >>>> It's fast to create (at least as fast as Access), it has more
features
> >>>> than Access etc.
> >>>>
> >>>> This is only one approach - it's similar to Access' one (I don't like
> >>>> any of them, though). If you need n-tiered application it's better to
> > do
> >>>> the dynamic grid creation. In both cases you can do it with VS out of
> >>>> the box or you can buy some 3rd party components.
> >>>>
> >>>> -- 
> >>>>
> >>>>
> >>>> Regards,
> >>>> Thomas
> >>>>
> >>>> -----------------------------------------
> >>>> NConstruct - Intelligent Software Factory
> >>>> http://www.nconstruct.com
> >>>> -----------------------------------------
> >>>>
> >>>
> >
> >


0
Baz
6/7/2007 9:00:27 AM
These are the relative speeds for connecting with backend databases (source: 
Microsoft).

1.0  ODBC API
1.1  Query pass-through (readonly way to get the data)
1.1  RDO (remote data objects) - Microsoft's only comment was "it is very 
fast".
125 - 150  Access dynasets via linked tables.

So the answer is to get the data from the backend database via query 
pass-throughs and to write changes back with RDO.

Implementation:

I have a program mdb on the client which creates a temporary data mdb on the 
client.  The middleware is written as a VB DLL for speed (compiled) and for 
use of RDO.  Prior to opening a form, the middleware
 - Creates tables in the data mdb using model tables saved in the program 
mdb as a templates
 - Links to data tables in temp.mdb (local link - not over the network)
 - Creates query pass-throughs for each table
 - Creates  append queries using the query pass-throughs as its source to 
load the local linked tables.
 - Fires the append queries (got the data now - Access is totally faked 
out - both for design and runtime)

The sql for each query pass-through is stored in the backend database. Here 
is a sample:

SELECT B.BudgetID, B.ChartAcntID, B.BudgetYear, B.January, B.February, 
B.March, B.April, B.May, B.June,
               B.July, B.August, B.September, B.October, B.November, 
B.December,
               CAST(B.TS AS CHAR) AS ExactTS
FROM Tiger.Budget AS B
WHERE B.BudgetYear = ::01
ORDER BY B.ChartAcntID

BudgetID  is the auto increment primary key issued by the database.  B.TS is 
a timestamp cast as char for concurrency. (Note: in .NET with SQL Server, 
you would cast B.TS as an int since SQL Server's timestamp is really a 
binary row version). ::01 is a placeholder for parameter tokens.

For children of parent tables, you would refire the append queries on the 
Form_Current event - i.e., you only have the invoice detail locally for one 
invoice.

  *** In the parent form ***
  ' Retrieve line items this order from Sybase and requery subform
  Set f = Me.zInvoiceLineitems.Form
  f.RequeryData lInvoiceID:=Nz(Me.InvoiceID, 0)
  Set f = Nothing

  *** In child form ***
  ReDim vNewTokenValues(1)
  vNewTokenValues(1) = lInvoiceID
  goTblsSybase.Item("InvoiceLineItem").RefreshData 
vNewTokenValues:=vNewTokenValues
  Me.Requery


Writing the data back is a little more tricky.  To do this, I have a 
CFormDataHandler class which each form instantiates.  Public methods include 
AddTimerItem, Form_AfterDelConfirm, Form_AfterInsert, Form_AfterUpdate, 
Form_Current, Form_Delete, Form_Timer, Form_Unload, Initialize and 
RefreshData.  Each form and each subform delegates activity back to the 
oFormDataHandler object.  The middleware figures out what the insert, 
delete, and update statements are from the initial select statement - sort 
of like .NET's command builder but smarter.

The framework is complex, but once it is written, it's really simple to use. 
Access is totally faked out.  It becomes a really fast single user database 
working only with local data.  Since you are not relying on linked tables 
across the network, reliability goes to 100% - it never breaks.  Plus all 
access to the backend database is at the ODBC API speed.

Since the initial project back in 1999, I've reused this framework on 
numerous projects.  For one, we had to connect via a really slow fractional 
T-1.  After making an entry in a cell in a grid, the client pressed the 
down-arrow key which caused the writeback to the database via the framework. 
The time to get to the next row was instantaneous.  The client said "wow, 
its like the server was right there".

This is the magic of disconnected data.  Think about it.  That is what 
ADO.NET is all about with its disconnected datasets.

They say "real programmers don't use bound forms".  From my experience, 
bound forms offer hugh productivty gains.  Access has it as does .NET.

Jim

"(PeteCresswell)" <x@y.Invalid> wrote in message 
news:72ge63pc38ien1kh3gktg1rafdorp6r044@4ax.com...
> Per Jim Rand:
>>So what to do, what to do?  The obvious question was to fix the data
>>marshalling in MS Access so that it is fast and reliable.
>>Did that.  My Access applications now run 125 times faster on the network
>>with bound forms to linked tables.
>
> Can you list some of the things you did to make that improvement
> in marshalling?
> -- 
> PeteCresswell 


0
Jim
6/7/2007 3:25:10 PM
Per Jim Rand:
>The framework is complex, but once it is written, it's really simple to use. 
>Access is totally faked out.  It becomes a really fast single user database 
>working only with local data.

You lost me on how you get the data from the back end into your
temp tables.   Is the back end SQL server?

Other than that part, it sounds like my SOP for running an app:
copy everything to temp tables on C: and then use bound forms
against the temp tables.

Seems to me like it's a happy compromise: the convenience and
services of bound objects, but close to the speed/lack of
contention/safety of unbound objects.

For a .MDB back end, I just use Append queries to write to temp
tables.   For SQL Server back ends, I'll write a stored procedure
that only hits the server once, but comes back with a data stream
for each temp table I need to populate.

I experimented with caching drop down rowsources once with a .MDB
back end, but I'm not sure that it helped performance any.   Last
SQL Server back end I did, caching the dropdowns helped
noticeably at form-open time.
-- 
PeteCresswell
0
PeteCresswell
6/7/2007 5:33:36 PM
(PeteCresswell) wrote:
> Per Jim Rand:
>> The framework is complex, but once it is written, it's really simple
>> to use. Access is totally faked out.  It becomes a really fast
>> single user database working only with local data.
>
> You lost me on how you get the data from the back end into your
> temp tables.   Is the back end SQL server?
>
> Other than that part, it sounds like my SOP for running an app:
> copy everything to temp tables on C: and then use bound forms
> against the temp tables.
>
> Seems to me like it's a happy compromise: the convenience and
> services of bound objects, but close to the speed/lack of
> contention/safety of unbound objects.
>
> For a .MDB back end, I just use Append queries to write to temp
> tables.   For SQL Server back ends, I'll write a stored procedure
> that only hits the server once, but comes back with a data stream
> for each temp table I need to populate.
>
> I experimented with caching drop down rowsources once with a .MDB
> back end, but I'm not sure that it helped performance any.   Last
> SQL Server back end I did, caching the dropdowns helped
> noticeably at form-open time.

How do you deal with concurrency?  Presumably a long time can pass between 
retreiving data into the temp tables and all changes being written back to 
the source.  How do you know some of those same records have not been 
changed by other users?

When people talk about the benefits of "disconnected" data I never 
understand how they can deal with this part.

-- 
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt   at   Hunter   dot   com


0
Rick
6/7/2007 5:55:17 PM
yes, you are wasting your time

Microsoft is going to make a new .NET version of ADP with the next release--  
so .NET is not a total waste of time

but it is obvious that ADP is a much much much better platform than .NET



"PMK" <expat_th-usenet@yahoo.ca> wrote in message 
news:4kf463th3up13cqnmq27ubbih4jt1lm6h4@4ax.com...
>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 


0
aaron_kempf
6/7/2007 7:00:39 PM
Where you should start?  Well, you should start with VB6, VC6, COM/DCOM/MTS, 
ActiveX and the registries base themselves!

In case you forgot, this whole system was already in the process of 
imploding under its own weigth 10 years ago. Doing a program today is no 
longer the process of aligning a few text boxes, comboboxes and listboxes on 
a simple form, tabbed form or continuous form on an isolated machine, 
without internet and maybe even without a LAN.

Take a look at all the criticisms that were made about VB6, unmanaged C++, 
the DLL hell, the total lack of security and the constant corruption of the 
registries base - to name only that - and now think about what would be the 
situation if instead of dumping that into the garbage bin, MS would have 
increasing the size of these dinosaurs by a factor of at least ten to one 
hundred.  Increasing the size of the registry base by a factor of at least 
one hundred is not only a reasonable assumption but it's quite likely a 
gross under-estimation of the true space that would have been required to 
cover the actual possibilities of the .NET framework using these old 
technologies.

I agree with you that even on a Core 2 Duo, running the actual Framework 2.0 
is slow but if you would have tried to do the same thing with 
COM/DCOM/ActiveX - as it was with VB6 - probably that not only your machine 
will be running slow but probably that it would have imploding into a black 
hole.

Buying a dual core is now standard and they will soon be replaced with quad 
core as the basic developer machine. (Probably that the price of the quad 
core will be cut by two this autumn, if not before.). Next year, you will 
start to see machines with 8 cores and from 16 to 32 Gigs of memory running 
Vista 64 bit as the basic machine bought by most developers.  With such 
power running in 2008, do you really think that people wanted to keep 
VB6/VC6 - with a few more gugus here and there - as their main developer 
tools?

VB6 was the most popular tool in the past years?  So do were DBase3, Lotus 
1-2-3 and Word Perfect.  Now, all these tools are gone because Ashton-Tate, 
Lotus and Word-Perfect Corporation were believing that whence you have 
reached a market share of 90% and more, you don't have to evolve anymore and 
your base of loyal users will remain with you for eternity.

-- 
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
> Where do I start?  How about the bloated, festering dotnet framework,
> redolent as it is with the promise of versioning nightmares in years 
> ahead?
> How about not being able to write unmanaged code in anything but C++?  How
> about it being so damned slow?  How about the IDE being so damned awful?
> How about MS's sheer, arrogant supidity in trying to kill the world's most
> popular development tool (I refer of course to VB6) without even providing
> backward compatibility?
>
> That's a few gripes about the big stuff, I could think of a lot more if I
> tried.  There's LOADS more stuff at the small level, my favourite in
> 2002/2003 was the godawful combo box which couldn't even do what a VB6 
> combo
> could do, let alone an Access combo.  Sure, you can build your own 
> controls,
> which is exactly what I did to get a half-decent combo box (or you can buy
> 'em if you didn't already think you'd wasted enough dosh on this garbage),
> but that's what you have to do all the time: so much of it doesn't quite
> work as you would expect or want that you spend all your damn time
> finding/creating workarounds and alternatives.
>
> Yeeeuk!  I don't blame you for puffing this stuff - you've got a living to
> make - but frankly it makes me ill.
>
> "Thomas" <thomas@nconstruct.com> wrote in message
> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>> I still don't know the reasons you were not satisfied with VS/.NET
>> (except that with learning time)?
>>
>>
>> Regards,
>> Thomas
>>
>> -----------------------------------------
>> NConstruct - Intelligent Software Factory
>> http://www.nconstruct.com
>> -----------------------------------------
>>
>>
>>
>>
>> Baz wrote:
>> > Yep, that sounds like advertising.  As I said, I own VS 2003
> Professional
>> > and I consider it to have been a complete waste of money.  I do not
> believe
>> > that VS 2005 can be so much better that it is worth me spending any 
>> > time
> on
>> > it, and I'm certainly not going to waste any money buying add-ons for
> it.
>> > I'd rather put my efforts into continuing my investigations into Delphi
> (not
>> > that I see Delphi as a serious contender to Access either for database
>> > applications, it's just that, for the odd occasion when I do something
> for
>> > which I don't consider Access suitable, I'd like to have a serious and
>> > current alternative to VB6).
>> >
>> > "Thomas" <thomas@nconstruct.com> wrote in message
>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>> >> component if you don't want, and you can still produce i.e. continuous
>> >> forms with DataGridView component. This is not the best solution but
>> >> either is not worse than Access (for which there is no free version at
>> >> all).
>> >>
>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>> >> Developer Express, ComponentOne, Infragistic etc. really produce very
>> >> usable products. Serious developer should at least try them before
> judge
>> >> about their usability or quality. They are also very cheap comparing 
>> >> to
>> >> the price of developing only few percent of their features. Maybe it
>> >> sounds like advertising but I really just buy them and use them, and I
>> >> want to share good experience with other developers.
>> >>
>> >>
>> >> Regards,
>> >> Thomas
>> >>
>> >> -----------------------------------------
>> >> NConstruct - Intelligent Software Factory
>> >> http://www.nconstruct.com
>> >> -----------------------------------------
>> >>
>> >>
>> >>
>> >>
>> >> Baz wrote:
>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>> >>> (having
>> >>> wasted a significant amount of my own money on upgrading from VS 6 to
> VS
>> >>> 2002/2003, and then concluding that it sucked so badly that I was
> simply
>> > not
>> >>> interested in using it).
>> >>>
>> >>> Nor am I impressed by a product which requires me to buy third-party
>> > add-ons
>> >>> in order for it to be anywhere near usable.
>> >>>
>> >>>
>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>> >>>> Baz wrote:
>> >>>>> I have two things to say to you: linked subforms and continuous
> forms.
>> >>>> Baz, I don't think this is an Access advantage. For example, look at
>> >>>> those tutorials:
>> >>>>
>> >
> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>> >
> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>> >>>> It's fast to create (at least as fast as Access), it has more
> features
>> >>>> than Access etc.
>> >>>>
>> >>>> This is only one approach - it's similar to Access' one (I don't 
>> >>>> like
>> >>>> any of them, though). If you need n-tiered application it's better 
>> >>>> to
>> > do
>> >>>> the dynamic grid creation. In both cases you can do it with VS out 
>> >>>> of
>> >>>> the box or you can buy some 3rd party components.
>> >>>>
>> >>>> -- 
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Thomas
>> >>>>
>> >>>> -----------------------------------------
>> >>>> NConstruct - Intelligent Software Factory
>> >>>> http://www.nconstruct.com
>> >>>> -----------------------------------------
>> >>>>
>> >>>
>> >
>> >
>
> 


0
Sylvain
6/7/2007 7:14:53 PM
I'm surprised you're so emphatic about this, Sylvain.  That's not like you, 
from what I've seen.

I have to go with Baz on this one.  Many, MANY people are moving away from 
the .NET framework (Delphi seems to be a popular choice) because VS 
2002/2003 were very slow, and while VS 2005 offers some improvements, I 
gather, it's still often sluggish when using managed code, and many VB6 
developers have no interest in learning C++ as the only unmanaged 
alternative.  And, of course, there's the nightmare of having to 
redistribute the megalith that is the Framework itself.

As for how fast it will eventually be on upcoming OS's/hardware, designing a 
system for stuff that's not out yet isn't usually the best idea, as people 
have to use this stuff today on their current OS and hardware, not a year or 
two (or more) from now.  I'm also a firm believer that the hardware 
shouldn't have to compensate for the underlying speed of the application.

I completely disagree that VB6 with COM/DCOM/ActiveX would be a "black 
hole".  Most tests have shown that in fact, it's significantly faster than 
..NET in most cases.  There are certainly some tests where .NET outperforms 
VB6, and it's a lot more capable in some areas like multithreading, but most 
of the articles I've read have put VB6 as 1.5 - 2x faster than the 
equivalent .NET code.

But regardless of any of that, even if VS 2005 works faster in any given 
scenario, Access is still VBA-based, and as such, you'd still be using COM, 
etc.  *If* you're going to use Access, which many people still prefer to 
..NET solutions, it makes sense that you'd supplement it with VB6/COM if 
necessary, rather than using .NET and having to go through Interop.

I will agree that it looks like VB6 is likely to die eventually, and 
unfortunately, Microsoft seems to have no understanding of why people are 
complaining about that fact.  An unmanaged version of VB with greater 
backwards compatibility has been suggested, and requested by thousands 
(http://classicvb.org/Petition/), but again, it seems unlikely. 
Nevertheless, VB6 continues to be supported on Vista, at least in some 
fashion, so I don't really see much of a problem continuing to use that for 
the time being.

All that said, if .NET is fast enough for you (and as I say, I gather 2005 
made improvements in that area), then certainly there's a lot to be said for 
it in terms of enterprise development, Internet development, etc.  So, as 
they say, "if it works, don't knock it."  For myself, however, the 
sluggishness was intolerable, and at least so far, I'm sticking with VB6 
DLLs to back up my Access projects where necessary.


Rob

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
wrote in message news:%23m5jYhTqHHA.3372@TK2MSFTNGP03.phx.gbl...
> Where you should start?  Well, you should start with VB6, VC6, 
> COM/DCOM/MTS, ActiveX and the registries base themselves!
>
> In case you forgot, this whole system was already in the process of 
> imploding under its own weigth 10 years ago. Doing a program today is no 
> longer the process of aligning a few text boxes, comboboxes and listboxes 
> on a simple form, tabbed form or continuous form on an isolated machine, 
> without internet and maybe even without a LAN.
>
> Take a look at all the criticisms that were made about VB6, unmanaged C++, 
> the DLL hell, the total lack of security and the constant corruption of 
> the registries base - to name only that - and now think about what would 
> be the situation if instead of dumping that into the garbage bin, MS would 
> have increasing the size of these dinosaurs by a factor of at least ten to 
> one hundred.  Increasing the size of the registry base by a factor of at 
> least one hundred is not only a reasonable assumption but it's quite 
> likely a gross under-estimation of the true space that would have been 
> required to cover the actual possibilities of the .NET framework using 
> these old technologies.
>
> I agree with you that even on a Core 2 Duo, running the actual Framework 
> 2.0 is slow but if you would have tried to do the same thing with 
> COM/DCOM/ActiveX - as it was with VB6 - probably that not only your 
> machine will be running slow but probably that it would have imploding 
> into a black hole.
>
> Buying a dual core is now standard and they will soon be replaced with 
> quad core as the basic developer machine. (Probably that the price of the 
> quad core will be cut by two this autumn, if not before.). Next year, you 
> will start to see machines with 8 cores and from 16 to 32 Gigs of memory 
> running Vista 64 bit as the basic machine bought by most developers.  With 
> such power running in 2008, do you really think that people wanted to keep 
> VB6/VC6 - with a few more gugus here and there - as their main developer 
> tools?
>
> VB6 was the most popular tool in the past years?  So do were DBase3, Lotus 
> 1-2-3 and Word Perfect.  Now, all these tools are gone because 
> Ashton-Tate, Lotus and Word-Perfect Corporation were believing that whence 
> you have reached a market share of 90% and more, you don't have to evolve 
> anymore and your base of loyal users will remain with you for eternity.
>
> -- 
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
>
> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
> news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
>> Where do I start?  How about the bloated, festering dotnet framework,
>> redolent as it is with the promise of versioning nightmares in years 
>> ahead?
>> How about not being able to write unmanaged code in anything but C++? 
>> How
>> about it being so damned slow?  How about the IDE being so damned awful?
>> How about MS's sheer, arrogant supidity in trying to kill the world's 
>> most
>> popular development tool (I refer of course to VB6) without even 
>> providing
>> backward compatibility?
>>
>> That's a few gripes about the big stuff, I could think of a lot more if I
>> tried.  There's LOADS more stuff at the small level, my favourite in
>> 2002/2003 was the godawful combo box which couldn't even do what a VB6 
>> combo
>> could do, let alone an Access combo.  Sure, you can build your own 
>> controls,
>> which is exactly what I did to get a half-decent combo box (or you can 
>> buy
>> 'em if you didn't already think you'd wasted enough dosh on this 
>> garbage),
>> but that's what you have to do all the time: so much of it doesn't quite
>> work as you would expect or want that you spend all your damn time
>> finding/creating workarounds and alternatives.
>>
>> Yeeeuk!  I don't blame you for puffing this stuff - you've got a living 
>> to
>> make - but frankly it makes me ill.
>>
>> "Thomas" <thomas@nconstruct.com> wrote in message
>> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>>> I still don't know the reasons you were not satisfied with VS/.NET
>>> (except that with learning time)?
>>>
>>>
>>> Regards,
>>> Thomas
>>>
>>> -----------------------------------------
>>> NConstruct - Intelligent Software Factory
>>> http://www.nconstruct.com
>>> -----------------------------------------
>>>
>>>
>>>
>>>
>>> Baz wrote:
>>> > Yep, that sounds like advertising.  As I said, I own VS 2003
>> Professional
>>> > and I consider it to have been a complete waste of money.  I do not
>> believe
>>> > that VS 2005 can be so much better that it is worth me spending any 
>>> > time
>> on
>>> > it, and I'm certainly not going to waste any money buying add-ons for
>> it.
>>> > I'd rather put my efforts into continuing my investigations into 
>>> > Delphi
>> (not
>>> > that I see Delphi as a serious contender to Access either for database
>>> > applications, it's just that, for the odd occasion when I do something
>> for
>>> > which I don't consider Access suitable, I'd like to have a serious and
>>> > current alternative to VB6).
>>> >
>>> > "Thomas" <thomas@nconstruct.com> wrote in message
>>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>>> >> component if you don't want, and you can still produce i.e. 
>>> >> continuous
>>> >> forms with DataGridView component. This is not the best solution but
>>> >> either is not worse than Access (for which there is no free version 
>>> >> at
>>> >> all).
>>> >>
>>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>>> >> Developer Express, ComponentOne, Infragistic etc. really produce very
>>> >> usable products. Serious developer should at least try them before
>> judge
>>> >> about their usability or quality. They are also very cheap comparing 
>>> >> to
>>> >> the price of developing only few percent of their features. Maybe it
>>> >> sounds like advertising but I really just buy them and use them, and 
>>> >> I
>>> >> want to share good experience with other developers.
>>> >>
>>> >>
>>> >> Regards,
>>> >> Thomas
>>> >>
>>> >> -----------------------------------------
>>> >> NConstruct - Intelligent Software Factory
>>> >> http://www.nconstruct.com
>>> >> -----------------------------------------
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Baz wrote:
>>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>>> >>> (having
>>> >>> wasted a significant amount of my own money on upgrading from VS 6 
>>> >>> to
>> VS
>>> >>> 2002/2003, and then concluding that it sucked so badly that I was
>> simply
>>> > not
>>> >>> interested in using it).
>>> >>>
>>> >>> Nor am I impressed by a product which requires me to buy third-party
>>> > add-ons
>>> >>> in order for it to be anywhere near usable.
>>> >>>
>>> >>>
>>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>> >>>> Baz wrote:
>>> >>>>> I have two things to say to you: linked subforms and continuous
>> forms.
>>> >>>> Baz, I don't think this is an Access advantage. For example, look 
>>> >>>> at
>>> >>>> those tutorials:
>>> >>>>
>>> >
>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>> >
>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>> >>>> It's fast to create (at least as fast as Access), it has more
>> features
>>> >>>> than Access etc.
>>> >>>>
>>> >>>> This is only one approach - it's similar to Access' one (I don't 
>>> >>>> like
>>> >>>> any of them, though). If you need n-tiered application it's better 
>>> >>>> to
>>> > do
>>> >>>> the dynamic grid creation. In both cases you can do it with VS out 
>>> >>>> of
>>> >>>> the box or you can buy some 3rd party components.
>>> >>>>
>>> >>>> -- 
>>> >>>>
>>> >>>>
>>> >>>> Regards,
>>> >>>> Thomas
>>> >>>>
>>> >>>> -----------------------------------------
>>> >>>> NConstruct - Intelligent Software Factory
>>> >>>> http://www.nconstruct.com
>>> >>>> -----------------------------------------
>>> >>>>
>>> >>>
>>> >
>>> >
>>
>>
>
> 


0
Robert
6/7/2007 8:04:00 PM
Per Rick Brandt:
>How do you deal with concurrency?  Presumably a long time can pass between 
>retreiving data into the temp tables and all changes being written back to 
>the source.  How do you know some of those same records have not been 
>changed by other users?
>
>When people talk about the benefits of "disconnected" data I never 
>understand how they can deal with this part.

I don't.   The term of art that I've heard is "Last In Wins".

If I had to do something in that vein with a .MDB, I guess it
would just be a field in the record - something like a LAN UserID
and a timestamp.   

But that's a whole new layer of complexity and programming effort
and the kind of apps I do aren't really exposed to concurrency
because of the small number of users.

So, I guess one cost of my approach is loss of JET's monitoring
of concurrency issues.
-- 
PeteCresswell
0
PeteCresswell
6/7/2007 10:44:19 PM
Per "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no
spam please)>:
>Buying a dual core is now standard and they will soon be replaced with quad 
>core as the basic developer machine. (Probably that the price of the quad 
>core will be cut by two this autumn, if not before.).

Tangential OT Question:  Given that I'm running XP Pro and 32-bit
MS Office, would I notice any speed increase from going to a dual
or quad core machine?
-- 
PeteCresswell
0
PeteCresswell
6/7/2007 10:47:00 PM
"(PeteCresswell)" <x@y.Invalid> wrote in
news:fb2h63tutdu9gu1ui1jcj731irjjrk33dh@4ax.com: 

> If I had to do something in that vein with a .MDB, I guess it
> would just be a field in the record - something like a LAN UserID
> and a timestamp.   
> 
> But that's a whole new layer of complexity and programming effort
> and the kind of apps I do aren't really exposed to concurrency
> because of the small number of users.
> 
> So, I guess one cost of my approach is loss of JET's monitoring
> of concurrency issues.

Then what's the benefit of editing local temporary tables? With that
small a user population, forms bound to the linked tables ought to
function just fine. 

What problem are you trying to solve with all the complexity you
introduce with your temp tables? 

-- 
David W. Fenton                  http://www.dfenton.com/ 
usenet at dfenton dot com    http://www.dfenton.com/DFA/
0
David
6/8/2007 1:53:21 AM
On Thu, 7 Jun 2007 12:00:39 -0700, <aaron_kempf@hotmail.com> wrote:

>yes, you are wasting your time
>
>Microsoft is going to make a new .NET version of ADP with the next release--  
>so .NET is not a total waste of time
>
>but it is obvious that ADP is a much much much better platform than .NET

..NET version of an Access Data Project? I don't get it. Tell me more.

Peter
0
PMK
6/8/2007 6:10:41 AM
PMK <expat_th-usenet@yahoo.ca> wrote:

>On Thu, 7 Jun 2007 12:00:39 -0700, <a a r o n _ k  e  m p f @hotmail.com> wrote:
>
>>yes, you are wasting your time
>>
>>Microsoft is going to make a new .NET version of ADP with the next release--  
>>so .NET is not a total waste of time
>>
>>but it is obvious that ADP is a much much much better platform than .NET
>
>.NET version of an Access Data Project? I don't get it. Tell me more.

Unfortunately Aaron Ke mpf's answer to every problem is ADPs.   

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.granite.ab.ca/accsmstr.htm
   Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
0
Tony
6/8/2007 9:12:08 PM
Well, I suppose that depends on the type of MS-Office application that you 
are using.  XP-Pro is multithread but many applications are not multithread 
or are poorly implementing any kind of multithread; so you should see no or 
little increase of performance.  Of course, Windows never stop doing 
something and practically all applications are doing things like I/O; so you 
will always benefit at least some advantage of running an application on a 
bigger machine but by how much?  I don't know.

However, you can tell that the more people will have dual and quad cores, 
the more the number of applications that will get tuned to use this kind of 
power.

-- 
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"(PeteCresswell)" <x@y.Invalid> wrote in message 
news:mk2h635kqp1hkbdapicn7p2qgmag39m2ee@4ax.com...
> Per "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no
> spam please)>:
>>Buying a dual core is now standard and they will soon be replaced with 
>>quad
>>core as the basic developer machine. (Probably that the price of the quad
>>core will be cut by two this autumn, if not before.).
>
> Tangential OT Question:  Given that I'm running XP Pro and 32-bit
> MS Office, would I notice any speed increase from going to a dual
> or quad core machine?
> -- 
> PeteCresswell 


0
Sylvain
6/12/2007 5:14:41 AM
Yeah, even me can get emphatic about something, sometime.  It's only that in 
this case (ADP), I got tired to hear people coming here to say that even if 
they know nothing about SQL-Server, ADP or .NET - from their own admission 
and they are proud of it, too - they will now tell us everything we need to 
know about these.

As to VB6, I agree with you that on many occasions, it will be faster than 
..NET.  The problem here is not the performance when you are doing old stuff 
like 10 years ago; the problem is when you want to have new stuff.  When was 
the last time that you have used some kind of datagrid control with VB6 and 
that you didn't have the taste of eating your own keyboard after a few days 
of work?

Something as simple as having rows of different colors can put VB6 or Access 
down to their knees and I won't speak here about stuff like having images or 
adding an unbound control to a continuous form or even something very basic 
like keeping the multi-rows selection active when the user click on a 
button.

When you need to add some extensibility of any kind, VB6/Access are simply 
not the way to go.

-- 
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
news:%238b%23c$TqHHA.1168@TK2MSFTNGP03.phx.gbl...
> I'm surprised you're so emphatic about this, Sylvain.  That's not like 
> you, from what I've seen.
>
> I have to go with Baz on this one.  Many, MANY people are moving away from 
> the .NET framework (Delphi seems to be a popular choice) because VS 
> 2002/2003 were very slow, and while VS 2005 offers some improvements, I 
> gather, it's still often sluggish when using managed code, and many VB6 
> developers have no interest in learning C++ as the only unmanaged 
> alternative.  And, of course, there's the nightmare of having to 
> redistribute the megalith that is the Framework itself.
>
> As for how fast it will eventually be on upcoming OS's/hardware, designing 
> a system for stuff that's not out yet isn't usually the best idea, as 
> people have to use this stuff today on their current OS and hardware, not 
> a year or two (or more) from now.  I'm also a firm believer that the 
> hardware shouldn't have to compensate for the underlying speed of the 
> application.
>
> I completely disagree that VB6 with COM/DCOM/ActiveX would be a "black 
> hole".  Most tests have shown that in fact, it's significantly faster than 
> .NET in most cases.  There are certainly some tests where .NET outperforms 
> VB6, and it's a lot more capable in some areas like multithreading, but 
> most of the articles I've read have put VB6 as 1.5 - 2x faster than the 
> equivalent .NET code.
>
> But regardless of any of that, even if VS 2005 works faster in any given 
> scenario, Access is still VBA-based, and as such, you'd still be using 
> COM, etc.  *If* you're going to use Access, which many people still prefer 
> to .NET solutions, it makes sense that you'd supplement it with VB6/COM if 
> necessary, rather than using .NET and having to go through Interop.
>
> I will agree that it looks like VB6 is likely to die eventually, and 
> unfortunately, Microsoft seems to have no understanding of why people are 
> complaining about that fact.  An unmanaged version of VB with greater 
> backwards compatibility has been suggested, and requested by thousands 
> (http://classicvb.org/Petition/), but again, it seems unlikely. 
> Nevertheless, VB6 continues to be supported on Vista, at least in some 
> fashion, so I don't really see much of a problem continuing to use that 
> for the time being.
>
> All that said, if .NET is fast enough for you (and as I say, I gather 2005 
> made improvements in that area), then certainly there's a lot to be said 
> for it in terms of enterprise development, Internet development, etc.  So, 
> as they say, "if it works, don't knock it."  For myself, however, the 
> sluggishness was intolerable, and at least so far, I'm sticking with VB6 
> DLLs to back up my Access projects where necessary.
>
>
> Rob
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
> wrote in message news:%23m5jYhTqHHA.3372@TK2MSFTNGP03.phx.gbl...
>> Where you should start?  Well, you should start with VB6, VC6, 
>> COM/DCOM/MTS, ActiveX and the registries base themselves!
>>
>> In case you forgot, this whole system was already in the process of 
>> imploding under its own weigth 10 years ago. Doing a program today is no 
>> longer the process of aligning a few text boxes, comboboxes and listboxes 
>> on a simple form, tabbed form or continuous form on an isolated machine, 
>> without internet and maybe even without a LAN.
>>
>> Take a look at all the criticisms that were made about VB6, unmanaged 
>> C++, the DLL hell, the total lack of security and the constant corruption 
>> of the registries base - to name only that - and now think about what 
>> would be the situation if instead of dumping that into the garbage bin, 
>> MS would have increasing the size of these dinosaurs by a factor of at 
>> least ten to one hundred.  Increasing the size of the registry base by a 
>> factor of at least one hundred is not only a reasonable assumption but 
>> it's quite likely a gross under-estimation of the true space that would 
>> have been required to cover the actual possibilities of the .NET 
>> framework using these old technologies.
>>
>> I agree with you that even on a Core 2 Duo, running the actual Framework 
>> 2.0 is slow but if you would have tried to do the same thing with 
>> COM/DCOM/ActiveX - as it was with VB6 - probably that not only your 
>> machine will be running slow but probably that it would have imploding 
>> into a black hole.
>>
>> Buying a dual core is now standard and they will soon be replaced with 
>> quad core as the basic developer machine. (Probably that the price of the 
>> quad core will be cut by two this autumn, if not before.). Next year, you 
>> will start to see machines with 8 cores and from 16 to 32 Gigs of memory 
>> running Vista 64 bit as the basic machine bought by most developers. 
>> With such power running in 2008, do you really think that people wanted 
>> to keep VB6/VC6 - with a few more gugus here and there - as their main 
>> developer tools?
>>
>> VB6 was the most popular tool in the past years?  So do were DBase3, 
>> Lotus 1-2-3 and Word Perfect.  Now, all these tools are gone because 
>> Ashton-Tate, Lotus and Word-Perfect Corporation were believing that 
>> whence you have reached a market share of 90% and more, you don't have to 
>> evolve anymore and your base of loyal users will remain with you for 
>> eternity.
>>
>> -- 
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
>> news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
>>> Where do I start?  How about the bloated, festering dotnet framework,
>>> redolent as it is with the promise of versioning nightmares in years 
>>> ahead?
>>> How about not being able to write unmanaged code in anything but C++? 
>>> How
>>> about it being so damned slow?  How about the IDE being so damned awful?
>>> How about MS's sheer, arrogant supidity in trying to kill the world's 
>>> most
>>> popular development tool (I refer of course to VB6) without even 
>>> providing
>>> backward compatibility?
>>>
>>> That's a few gripes about the big stuff, I could think of a lot more if 
>>> I
>>> tried.  There's LOADS more stuff at the small level, my favourite in
>>> 2002/2003 was the godawful combo box which couldn't even do what a VB6 
>>> combo
>>> could do, let alone an Access combo.  Sure, you can build your own 
>>> controls,
>>> which is exactly what I did to get a half-decent combo box (or you can 
>>> buy
>>> 'em if you didn't already think you'd wasted enough dosh on this 
>>> garbage),
>>> but that's what you have to do all the time: so much of it doesn't quite
>>> work as you would expect or want that you spend all your damn time
>>> finding/creating workarounds and alternatives.
>>>
>>> Yeeeuk!  I don't blame you for puffing this stuff - you've got a living 
>>> to
>>> make - but frankly it makes me ill.
>>>
>>> "Thomas" <thomas@nconstruct.com> wrote in message
>>> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>>>> I still don't know the reasons you were not satisfied with VS/.NET
>>>> (except that with learning time)?
>>>>
>>>>
>>>> Regards,
>>>> Thomas
>>>>
>>>> -----------------------------------------
>>>> NConstruct - Intelligent Software Factory
>>>> http://www.nconstruct.com
>>>> -----------------------------------------
>>>>
>>>>
>>>>
>>>>
>>>> Baz wrote:
>>>> > Yep, that sounds like advertising.  As I said, I own VS 2003
>>> Professional
>>>> > and I consider it to have been a complete waste of money.  I do not
>>> believe
>>>> > that VS 2005 can be so much better that it is worth me spending any 
>>>> > time
>>> on
>>>> > it, and I'm certainly not going to waste any money buying add-ons for
>>> it.
>>>> > I'd rather put my efforts into continuing my investigations into 
>>>> > Delphi
>>> (not
>>>> > that I see Delphi as a serious contender to Access either for 
>>>> > database
>>>> > applications, it's just that, for the odd occasion when I do 
>>>> > something
>>> for
>>>> > which I don't consider Access suitable, I'd like to have a serious 
>>>> > and
>>>> > current alternative to VB6).
>>>> >
>>>> > "Thomas" <thomas@nconstruct.com> wrote in message
>>>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>>>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>>>> >> component if you don't want, and you can still produce i.e. 
>>>> >> continuous
>>>> >> forms with DataGridView component. This is not the best solution but
>>>> >> either is not worse than Access (for which there is no free version 
>>>> >> at
>>>> >> all).
>>>> >>
>>>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>>>> >> Developer Express, ComponentOne, Infragistic etc. really produce 
>>>> >> very
>>>> >> usable products. Serious developer should at least try them before
>>> judge
>>>> >> about their usability or quality. They are also very cheap comparing 
>>>> >> to
>>>> >> the price of developing only few percent of their features. Maybe it
>>>> >> sounds like advertising but I really just buy them and use them, and 
>>>> >> I
>>>> >> want to share good experience with other developers.
>>>> >>
>>>> >>
>>>> >> Regards,
>>>> >> Thomas
>>>> >>
>>>> >> -----------------------------------------
>>>> >> NConstruct - Intelligent Software Factory
>>>> >> http://www.nconstruct.com
>>>> >> -----------------------------------------
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> Baz wrote:
>>>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>>>> >>> (having
>>>> >>> wasted a significant amount of my own money on upgrading from VS 6 
>>>> >>> to
>>> VS
>>>> >>> 2002/2003, and then concluding that it sucked so badly that I was
>>> simply
>>>> > not
>>>> >>> interested in using it).
>>>> >>>
>>>> >>> Nor am I impressed by a product which requires me to buy 
>>>> >>> third-party
>>>> > add-ons
>>>> >>> in order for it to be anywhere near usable.
>>>> >>>
>>>> >>>
>>>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>>> >>>> Baz wrote:
>>>> >>>>> I have two things to say to you: linked subforms and continuous
>>> forms.
>>>> >>>> Baz, I don't think this is an Access advantage. For example, look 
>>>> >>>> at
>>>> >>>> those tutorials:
>>>> >>>>
>>>> >
>>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>>> >
>>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>> >>>> It's fast to create (at least as fast as Access), it has more
>>> features
>>>> >>>> than Access etc.
>>>> >>>>
>>>> >>>> This is only one approach - it's similar to Access' one (I don't 
>>>> >>>> like
>>>> >>>> any of them, though). If you need n-tiered application it's better 
>>>> >>>> to
>>>> > do
>>>> >>>> the dynamic grid creation. In both cases you can do it with VS out 
>>>> >>>> of
>>>> >>>> the box or you can buy some 3rd party components.
>>>> >>>>
>>>> >>>> -- 
>>>> >>>>
>>>> >>>>
>>>> >>>> Regards,
>>>> >>>> Thomas
>>>> >>>>
>>>> >>>> -----------------------------------------
>>>> >>>> NConstruct - Intelligent Software Factory
>>>> >>>> http://www.nconstruct.com
>>>> >>>> -----------------------------------------
>>>> >>>>
>>>> >>>
>>>> >
>>>> >
>>>
>>>
>>
>>
>
> 


0
Sylvain
6/12/2007 6:16:19 AM
Yeah, okay, for the type of issues you're talking about, I can see .NET 
being more useful.  Last time I tried it, though, it was unacceptably slow, 
and until someone can prove to me that the speed is now more 
acceptable--which I've heard for 2005--and that there's a decent upgrade 
path from VB6 (or better yet Access)--which I've never heard from 
anybody--it won't ever be on my list of things to upgrade to.



Rob

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
wrote in message news:eIy$dlLrHHA.532@TK2MSFTNGP06.phx.gbl...
> Yeah, even me can get emphatic about something, sometime.  It's only that 
> in this case (ADP), I got tired to hear people coming here to say that 
> even if they know nothing about SQL-Server, ADP or .NET - from their own 
> admission and they are proud of it, too - they will now tell us everything 
> we need to know about these.
>
> As to VB6, I agree with you that on many occasions, it will be faster than 
> .NET.  The problem here is not the performance when you are doing old 
> stuff like 10 years ago; the problem is when you want to have new stuff. 
> When was the last time that you have used some kind of datagrid control 
> with VB6 and that you didn't have the taste of eating your own keyboard 
> after a few days of work?
>
> Something as simple as having rows of different colors can put VB6 or 
> Access down to their knees and I won't speak here about stuff like having 
> images or adding an unbound control to a continuous form or even something 
> very basic like keeping the multi-rows selection active when the user 
> click on a button.
>
> When you need to add some extensibility of any kind, VB6/Access are simply 
> not the way to go.
>
> -- 
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
>
> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
> news:%238b%23c$TqHHA.1168@TK2MSFTNGP03.phx.gbl...
>> I'm surprised you're so emphatic about this, Sylvain.  That's not like 
>> you, from what I've seen.
>>
>> I have to go with Baz on this one.  Many, MANY people are moving away 
>> from the .NET framework (Delphi seems to be a popular choice) because VS 
>> 2002/2003 were very slow, and while VS 2005 offers some improvements, I 
>> gather, it's still often sluggish when using managed code, and many VB6 
>> developers have no interest in learning C++ as the only unmanaged 
>> alternative.  And, of course, there's the nightmare of having to 
>> redistribute the megalith that is the Framework itself.
>>
>> As for how fast it will eventually be on upcoming OS's/hardware, 
>> designing a system for stuff that's not out yet isn't usually the best 
>> idea, as people have to use this stuff today on their current OS and 
>> hardware, not a year or two (or more) from now.  I'm also a firm believer 
>> that the hardware shouldn't have to compensate for the underlying speed 
>> of the application.
>>
>> I completely disagree that VB6 with COM/DCOM/ActiveX would be a "black 
>> hole".  Most tests have shown that in fact, it's significantly faster 
>> than .NET in most cases.  There are certainly some tests where .NET 
>> outperforms VB6, and it's a lot more capable in some areas like 
>> multithreading, but most of the articles I've read have put VB6 as 1.5 - 
>> 2x faster than the equivalent .NET code.
>>
>> But regardless of any of that, even if VS 2005 works faster in any given 
>> scenario, Access is still VBA-based, and as such, you'd still be using 
>> COM, etc.  *If* you're going to use Access, which many people still 
>> prefer to .NET solutions, it makes sense that you'd supplement it with 
>> VB6/COM if necessary, rather than using .NET and having to go through 
>> Interop.
>>
>> I will agree that it looks like VB6 is likely to die eventually, and 
>> unfortunately, Microsoft seems to have no understanding of why people are 
>> complaining about that fact.  An unmanaged version of VB with greater 
>> backwards compatibility has been suggested, and requested by thousands 
>> (http://classicvb.org/Petition/), but again, it seems unlikely. 
>> Nevertheless, VB6 continues to be supported on Vista, at least in some 
>> fashion, so I don't really see much of a problem continuing to use that 
>> for the time being.
>>
>> All that said, if .NET is fast enough for you (and as I say, I gather 
>> 2005 made improvements in that area), then certainly there's a lot to be 
>> said for it in terms of enterprise development, Internet development, 
>> etc.  So, as they say, "if it works, don't knock it."  For myself, 
>> however, the sluggishness was intolerable, and at least so far, I'm 
>> sticking with VB6 DLLs to back up my Access projects where necessary.
>>
>>
>> Rob
>>
>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
>> wrote in message news:%23m5jYhTqHHA.3372@TK2MSFTNGP03.phx.gbl...
>>> Where you should start?  Well, you should start with VB6, VC6, 
>>> COM/DCOM/MTS, ActiveX and the registries base themselves!
>>>
>>> In case you forgot, this whole system was already in the process of 
>>> imploding under its own weigth 10 years ago. Doing a program today is no 
>>> longer the process of aligning a few text boxes, comboboxes and 
>>> listboxes on a simple form, tabbed form or continuous form on an 
>>> isolated machine, without internet and maybe even without a LAN.
>>>
>>> Take a look at all the criticisms that were made about VB6, unmanaged 
>>> C++, the DLL hell, the total lack of security and the constant 
>>> corruption of the registries base - to name only that - and now think 
>>> about what would be the situation if instead of dumping that into the 
>>> garbage bin, MS would have increasing the size of these dinosaurs by a 
>>> factor of at least ten to one hundred.  Increasing the size of the 
>>> registry base by a factor of at least one hundred is not only a 
>>> reasonable assumption but it's quite likely a gross under-estimation of 
>>> the true space that would have been required to cover the actual 
>>> possibilities of the .NET framework using these old technologies.
>>>
>>> I agree with you that even on a Core 2 Duo, running the actual Framework 
>>> 2.0 is slow but if you would have tried to do the same thing with 
>>> COM/DCOM/ActiveX - as it was with VB6 - probably that not only your 
>>> machine will be running slow but probably that it would have imploding 
>>> into a black hole.
>>>
>>> Buying a dual core is now standard and they will soon be replaced with 
>>> quad core as the basic developer machine. (Probably that the price of 
>>> the quad core will be cut by two this autumn, if not before.). Next 
>>> year, you will start to see machines with 8 cores and from 16 to 32 Gigs 
>>> of memory running Vista 64 bit as the basic machine bought by most 
>>> developers. With such power running in 2008, do you really think that 
>>> people wanted to keep VB6/VC6 - with a few more gugus here and there - 
>>> as their main developer tools?
>>>
>>> VB6 was the most popular tool in the past years?  So do were DBase3, 
>>> Lotus 1-2-3 and Word Perfect.  Now, all these tools are gone because 
>>> Ashton-Tate, Lotus and Word-Perfect Corporation were believing that 
>>> whence you have reached a market share of 90% and more, you don't have 
>>> to evolve anymore and your base of loyal users will remain with you for 
>>> eternity.
>>>
>>> -- 
>>> Sylvain Lafontaine, ing.
>>> MVP - Technologies Virtual-PC
>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>
>>>
>>> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
>>> news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
>>>> Where do I start?  How about the bloated, festering dotnet framework,
>>>> redolent as it is with the promise of versioning nightmares in years 
>>>> ahead?
>>>> How about not being able to write unmanaged code in anything but C++? 
>>>> How
>>>> about it being so damned slow?  How about the IDE being so damned 
>>>> awful?
>>>> How about MS's sheer, arrogant supidity in trying to kill the world's 
>>>> most
>>>> popular development tool (I refer of course to VB6) without even 
>>>> providing
>>>> backward compatibility?
>>>>
>>>> That's a few gripes about the big stuff, I could think of a lot more if 
>>>> I
>>>> tried.  There's LOADS more stuff at the small level, my favourite in
>>>> 2002/2003 was the godawful combo box which couldn't even do what a VB6 
>>>> combo
>>>> could do, let alone an Access combo.  Sure, you can build your own 
>>>> controls,
>>>> which is exactly what I did to get a half-decent combo box (or you can 
>>>> buy
>>>> 'em if you didn't already think you'd wasted enough dosh on this 
>>>> garbage),
>>>> but that's what you have to do all the time: so much of it doesn't 
>>>> quite
>>>> work as you would expect or want that you spend all your damn time
>>>> finding/creating workarounds and alternatives.
>>>>
>>>> Yeeeuk!  I don't blame you for puffing this stuff - you've got a living 
>>>> to
>>>> make - but frankly it makes me ill.
>>>>
>>>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>>>>> I still don't know the reasons you were not satisfied with VS/.NET
>>>>> (except that with learning time)?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Thomas
>>>>>
>>>>> -----------------------------------------
>>>>> NConstruct - Intelligent Software Factory
>>>>> http://www.nconstruct.com
>>>>> -----------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Baz wrote:
>>>>> > Yep, that sounds like advertising.  As I said, I own VS 2003
>>>> Professional
>>>>> > and I consider it to have been a complete waste of money.  I do not
>>>> believe
>>>>> > that VS 2005 can be so much better that it is worth me spending any 
>>>>> > time
>>>> on
>>>>> > it, and I'm certainly not going to waste any money buying add-ons 
>>>>> > for
>>>> it.
>>>>> > I'd rather put my efforts into continuing my investigations into 
>>>>> > Delphi
>>>> (not
>>>>> > that I see Delphi as a serious contender to Access either for 
>>>>> > database
>>>>> > applications, it's just that, for the odd occasion when I do 
>>>>> > something
>>>> for
>>>>> > which I don't consider Access suitable, I'd like to have a serious 
>>>>> > and
>>>>> > current alternative to VB6).
>>>>> >
>>>>> > "Thomas" <thomas@nconstruct.com> wrote in message
>>>>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>>>>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>>>>> >> component if you don't want, and you can still produce i.e. 
>>>>> >> continuous
>>>>> >> forms with DataGridView component. This is not the best solution 
>>>>> >> but
>>>>> >> either is not worse than Access (for which there is no free version 
>>>>> >> at
>>>>> >> all).
>>>>> >>
>>>>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>>>>> >> Developer Express, ComponentOne, Infragistic etc. really produce 
>>>>> >> very
>>>>> >> usable products. Serious developer should at least try them before
>>>> judge
>>>>> >> about their usability or quality. They are also very cheap 
>>>>> >> comparing to
>>>>> >> the price of developing only few percent of their features. Maybe 
>>>>> >> it
>>>>> >> sounds like advertising but I really just buy them and use them, 
>>>>> >> and I
>>>>> >> want to share good experience with other developers.
>>>>> >>
>>>>> >>
>>>>> >> Regards,
>>>>> >> Thomas
>>>>> >>
>>>>> >> -----------------------------------------
>>>>> >> NConstruct - Intelligent Software Factory
>>>>> >> http://www.nconstruct.com
>>>>> >> -----------------------------------------
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Baz wrote:
>>>>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>>>>> >>> (having
>>>>> >>> wasted a significant amount of my own money on upgrading from VS 6 
>>>>> >>> to
>>>> VS
>>>>> >>> 2002/2003, and then concluding that it sucked so badly that I was
>>>> simply
>>>>> > not
>>>>> >>> interested in using it).
>>>>> >>>
>>>>> >>> Nor am I impressed by a product which requires me to buy 
>>>>> >>> third-party
>>>>> > add-ons
>>>>> >>> in order for it to be anywhere near usable.
>>>>> >>>
>>>>> >>>
>>>>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>>>> >>>> Baz wrote:
>>>>> >>>>> I have two things to say to you: linked subforms and continuous
>>>> forms.
>>>>> >>>> Baz, I don't think this is an Access advantage. For example, look 
>>>>> >>>> at
>>>>> >>>> those tutorials:
>>>>> >>>>
>>>>> >
>>>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>>>> >
>>>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>>> >>>> It's fast to create (at least as fast as Access), it has more
>>>> features
>>>>> >>>> than Access etc.
>>>>> >>>>
>>>>> >>>> This is only one approach - it's similar to Access' one (I don't 
>>>>> >>>> like
>>>>> >>>> any of them, though). If you need n-tiered application it's 
>>>>> >>>> better to
>>>>> > do
>>>>> >>>> the dynamic grid creation. In both cases you can do it with VS 
>>>>> >>>> out of
>>>>> >>>> the box or you can buy some 3rd party components.
>>>>> >>>>
>>>>> >>>> -- 
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Regards,
>>>>> >>>> Thomas
>>>>> >>>>
>>>>> >>>> -----------------------------------------
>>>>> >>>> NConstruct - Intelligent Software Factory
>>>>> >>>> http://www.nconstruct.com
>>>>> >>>> -----------------------------------------
>>>>> >>>>
>>>>> >>>
>>>>> >
>>>>> >
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


0
Robert
6/12/2007 6:38:03 PM
There is no doubt that in comparaison of VB6/VBA, you need a lot of firing 
power inside your machine to tame .NET but this is precisely what we are in 
the process of getting this year as the basic configuration for a new 
machine.

As for a decent upgrading path from Access, this is probably something we 
should see next year.  The SSMA-Access is already written in .NET, so I 
won't be surprised if in one year or two there is a new version to upgrade 
not only the backend to SQL-Server but also the frontend to .NET (and of 
course with the option of upgrading only the FE, without touching the BE).

-- 
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
news:%23IT9SGSrHHA.4324@TK2MSFTNGP04.phx.gbl...
> Yeah, okay, for the type of issues you're talking about, I can see .NET 
> being more useful.  Last time I tried it, though, it was unacceptably 
> slow, and until someone can prove to me that the speed is now more 
> acceptable--which I've heard for 2005--and that there's a decent upgrade 
> path from VB6 (or better yet Access)--which I've never heard from 
> anybody--it won't ever be on my list of things to upgrade to.
>
>
>
> Rob
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
> wrote in message news:eIy$dlLrHHA.532@TK2MSFTNGP06.phx.gbl...
>> Yeah, even me can get emphatic about something, sometime.  It's only that 
>> in this case (ADP), I got tired to hear people coming here to say that 
>> even if they know nothing about SQL-Server, ADP or .NET - from their own 
>> admission and they are proud of it, too - they will now tell us 
>> everything we need to know about these.
>>
>> As to VB6, I agree with you that on many occasions, it will be faster 
>> than .NET.  The problem here is not the performance when you are doing 
>> old stuff like 10 years ago; the problem is when you want to have new 
>> stuff. When was the last time that you have used some kind of datagrid 
>> control with VB6 and that you didn't have the taste of eating your own 
>> keyboard after a few days of work?
>>
>> Something as simple as having rows of different colors can put VB6 or 
>> Access down to their knees and I won't speak here about stuff like having 
>> images or adding an unbound control to a continuous form or even 
>> something very basic like keeping the multi-rows selection active when 
>> the user click on a button.
>>
>> When you need to add some extensibility of any kind, VB6/Access are 
>> simply not the way to go.
>>
>> -- 
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
>> news:%238b%23c$TqHHA.1168@TK2MSFTNGP03.phx.gbl...
>>> I'm surprised you're so emphatic about this, Sylvain.  That's not like 
>>> you, from what I've seen.
>>>
>>> I have to go with Baz on this one.  Many, MANY people are moving away 
>>> from the .NET framework (Delphi seems to be a popular choice) because VS 
>>> 2002/2003 were very slow, and while VS 2005 offers some improvements, I 
>>> gather, it's still often sluggish when using managed code, and many VB6 
>>> developers have no interest in learning C++ as the only unmanaged 
>>> alternative.  And, of course, there's the nightmare of having to 
>>> redistribute the megalith that is the Framework itself.
>>>
>>> As for how fast it will eventually be on upcoming OS's/hardware, 
>>> designing a system for stuff that's not out yet isn't usually the best 
>>> idea, as people have to use this stuff today on their current OS and 
>>> hardware, not a year or two (or more) from now.  I'm also a firm 
>>> believer that the hardware shouldn't have to compensate for the 
>>> underlying speed of the application.
>>>
>>> I completely disagree that VB6 with COM/DCOM/ActiveX would be a "black 
>>> hole".  Most tests have shown that in fact, it's significantly faster 
>>> than .NET in most cases.  There are certainly some tests where .NET 
>>> outperforms VB6, and it's a lot more capable in some areas like 
>>> multithreading, but most of the articles I've read have put VB6 as 1.5 - 
>>> 2x faster than the equivalent .NET code.
>>>
>>> But regardless of any of that, even if VS 2005 works faster in any given 
>>> scenario, Access is still VBA-based, and as such, you'd still be using 
>>> COM, etc.  *If* you're going to use Access, which many people still 
>>> prefer to .NET solutions, it makes sense that you'd supplement it with 
>>> VB6/COM if necessary, rather than using .NET and having to go through 
>>> Interop.
>>>
>>> I will agree that it looks like VB6 is likely to die eventually, and 
>>> unfortunately, Microsoft seems to have no understanding of why people 
>>> are complaining about that fact.  An unmanaged version of VB with 
>>> greater backwards compatibility has been suggested, and requested by 
>>> thousands (http://classicvb.org/Petition/), but again, it seems 
>>> unlikely. Nevertheless, VB6 continues to be supported on Vista, at least 
>>> in some fashion, so I don't really see much of a problem continuing to 
>>> use that for the time being.
>>>
>>> All that said, if .NET is fast enough for you (and as I say, I gather 
>>> 2005 made improvements in that area), then certainly there's a lot to be 
>>> said for it in terms of enterprise development, Internet development, 
>>> etc.  So, as they say, "if it works, don't knock it."  For myself, 
>>> however, the sluggishness was intolerable, and at least so far, I'm 
>>> sticking with VB6 DLLs to back up my Access projects where necessary.
>>>
>>>
>>> Rob
>>>
>>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
>>> wrote in message news:%23m5jYhTqHHA.3372@TK2MSFTNGP03.phx.gbl...
>>>> Where you should start?  Well, you should start with VB6, VC6, 
>>>> COM/DCOM/MTS, ActiveX and the registries base themselves!
>>>>
>>>> In case you forgot, this whole system was already in the process of 
>>>> imploding under its own weigth 10 years ago. Doing a program today is 
>>>> no longer the process of aligning a few text boxes, comboboxes and 
>>>> listboxes on a simple form, tabbed form or continuous form on an 
>>>> isolated machine, without internet and maybe even without a LAN.
>>>>
>>>> Take a look at all the criticisms that were made about VB6, unmanaged 
>>>> C++, the DLL hell, the total lack of security and the constant 
>>>> corruption of the registries base - to name only that - and now think 
>>>> about what would be the situation if instead of dumping that into the 
>>>> garbage bin, MS would have increasing the size of these dinosaurs by a 
>>>> factor of at least ten to one hundred.  Increasing the size of the 
>>>> registry base by a factor of at least one hundred is not only a 
>>>> reasonable assumption but it's quite likely a gross under-estimation of 
>>>> the true space that would have been required to cover the actual 
>>>> possibilities of the .NET framework using these old technologies.
>>>>
>>>> I agree with you that even on a Core 2 Duo, running the actual 
>>>> Framework 2.0 is slow but if you would have tried to do the same thing 
>>>> with COM/DCOM/ActiveX - as it was with VB6 - probably that not only 
>>>> your machine will be running slow but probably that it would have 
>>>> imploding into a black hole.
>>>>
>>>> Buying a dual core is now standard and they will soon be replaced with 
>>>> quad core as the basic developer machine. (Probably that the price of 
>>>> the quad core will be cut by two this autumn, if not before.). Next 
>>>> year, you will start to see machines with 8 cores and from 16 to 32 
>>>> Gigs of memory running Vista 64 bit as the basic machine bought by most 
>>>> developers. With such power running in 2008, do you really think that 
>>>> people wanted to keep VB6/VC6 - with a few more gugus here and there - 
>>>> as their main developer tools?
>>>>
>>>> VB6 was the most popular tool in the past years?  So do were DBase3, 
>>>> Lotus 1-2-3 and Word Perfect.  Now, all these tools are gone because 
>>>> Ashton-Tate, Lotus and Word-Perfect Corporation were believing that 
>>>> whence you have reached a market share of 90% and more, you don't have 
>>>> to evolve anymore and your base of loyal users will remain with you for 
>>>> eternity.
>>>>
>>>> -- 
>>>> Sylvain Lafontaine, ing.
>>>> MVP - Technologies Virtual-PC
>>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>>
>>>>
>>>> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
>>>> news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
>>>>> Where do I start?  How about the bloated, festering dotnet framework,
>>>>> redolent as it is with the promise of versioning nightmares in years 
>>>>> ahead?
>>>>> How about not being able to write unmanaged code in anything but C++? 
>>>>> How
>>>>> about it being so damned slow?  How about the IDE being so damned 
>>>>> awful?
>>>>> How about MS's sheer, arrogant supidity in trying to kill the world's 
>>>>> most
>>>>> popular development tool (I refer of course to VB6) without even 
>>>>> providing
>>>>> backward compatibility?
>>>>>
>>>>> That's a few gripes about the big stuff, I could think of a lot more 
>>>>> if I
>>>>> tried.  There's LOADS more stuff at the small level, my favourite in
>>>>> 2002/2003 was the godawful combo box which couldn't even do what a VB6 
>>>>> combo
>>>>> could do, let alone an Access combo.  Sure, you can build your own 
>>>>> controls,
>>>>> which is exactly what I did to get a half-decent combo box (or you can 
>>>>> buy
>>>>> 'em if you didn't already think you'd wasted enough dosh on this 
>>>>> garbage),
>>>>> but that's what you have to do all the time: so much of it doesn't 
>>>>> quite
>>>>> work as you would expect or want that you spend all your damn time
>>>>> finding/creating workarounds and alternatives.
>>>>>
>>>>> Yeeeuk!  I don't blame you for puffing this stuff - you've got a 
>>>>> living to
>>>>> make - but frankly it makes me ill.
>>>>>
>>>>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>>>>>> I still don't know the reasons you were not satisfied with VS/.NET
>>>>>> (except that with learning time)?
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Thomas
>>>>>>
>>>>>> -----------------------------------------
>>>>>> NConstruct - Intelligent Software Factory
>>>>>> http://www.nconstruct.com
>>>>>> -----------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Baz wrote:
>>>>>> > Yep, that sounds like advertising.  As I said, I own VS 2003
>>>>> Professional
>>>>>> > and I consider it to have been a complete waste of money.  I do not
>>>>> believe
>>>>>> > that VS 2005 can be so much better that it is worth me spending any 
>>>>>> > time
>>>>> on
>>>>>> > it, and I'm certainly not going to waste any money buying add-ons 
>>>>>> > for
>>>>> it.
>>>>>> > I'd rather put my efforts into continuing my investigations into 
>>>>>> > Delphi
>>>>> (not
>>>>>> > that I see Delphi as a serious contender to Access either for 
>>>>>> > database
>>>>>> > applications, it's just that, for the odd occasion when I do 
>>>>>> > something
>>>>> for
>>>>>> > which I don't consider Access suitable, I'd like to have a serious 
>>>>>> > and
>>>>>> > current alternative to VB6).
>>>>>> >
>>>>>> > "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>>>>>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>>>>>> >> component if you don't want, and you can still produce i.e. 
>>>>>> >> continuous
>>>>>> >> forms with DataGridView component. This is not the best solution 
>>>>>> >> but
>>>>>> >> either is not worse than Access (for which there is no free 
>>>>>> >> version at
>>>>>> >> all).
>>>>>> >>
>>>>>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>>>>>> >> Developer Express, ComponentOne, Infragistic etc. really produce 
>>>>>> >> very
>>>>>> >> usable products. Serious developer should at least try them before
>>>>> judge
>>>>>> >> about their usability or quality. They are also very cheap 
>>>>>> >> comparing to
>>>>>> >> the price of developing only few percent of their features. Maybe 
>>>>>> >> it
>>>>>> >> sounds like advertising but I really just buy them and use them, 
>>>>>> >> and I
>>>>>> >> want to share good experience with other developers.
>>>>>> >>
>>>>>> >>
>>>>>> >> Regards,
>>>>>> >> Thomas
>>>>>> >>
>>>>>> >> -----------------------------------------
>>>>>> >> NConstruct - Intelligent Software Factory
>>>>>> >> http://www.nconstruct.com
>>>>>> >> -----------------------------------------
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> Baz wrote:
>>>>>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>>>>>> >>> (having
>>>>>> >>> wasted a significant amount of my own money on upgrading from VS 
>>>>>> >>> 6 to
>>>>> VS
>>>>>> >>> 2002/2003, and then concluding that it sucked so badly that I was
>>>>> simply
>>>>>> > not
>>>>>> >>> interested in using it).
>>>>>> >>>
>>>>>> >>> Nor am I impressed by a product which requires me to buy 
>>>>>> >>> third-party
>>>>>> > add-ons
>>>>>> >>> in order for it to be anywhere near usable.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>>>>> >>>> Baz wrote:
>>>>>> >>>>> I have two things to say to you: linked subforms and continuous
>>>>> forms.
>>>>>> >>>> Baz, I don't think this is an Access advantage. For example, 
>>>>>> >>>> look at
>>>>>> >>>> those tutorials:
>>>>>> >>>>
>>>>>> >
>>>>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>>>>> >
>>>>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>>>> >>>> It's fast to create (at least as fast as Access), it has more
>>>>> features
>>>>>> >>>> than Access etc.
>>>>>> >>>>
>>>>>> >>>> This is only one approach - it's similar to Access' one (I don't 
>>>>>> >>>> like
>>>>>> >>>> any of them, though). If you need n-tiered application it's 
>>>>>> >>>> better to
>>>>>> > do
>>>>>> >>>> the dynamic grid creation. In both cases you can do it with VS 
>>>>>> >>>> out of
>>>>>> >>>> the box or you can buy some 3rd party components.
>>>>>> >>>>
>>>>>> >>>> -- 
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Regards,
>>>>>> >>>> Thomas
>>>>>> >>>>
>>>>>> >>>> -----------------------------------------
>>>>>> >>>> NConstruct - Intelligent Software Factory
>>>>>> >>>> http://www.nconstruct.com
>>>>>> >>>> -----------------------------------------
>>>>>> >>>>
>>>>>> >>>
>>>>>> >
>>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


0
Sylvain
6/13/2007 1:27:44 AM
Ummm...have you ever used the VB6 to VB.NET "Upgrade" Wizard?  IIRC, it 
doesn't upgrade forms at all, and it does a less-than-stellar job at 
upgrading VB6 code.  I can't say I have confidence in MS to write something 
that will upgrade my FE in a way that would be better than simply starting 
from scratch.  (For me personally, my BE is already SQL Server, so that's 
not an issue, though obviously that's strictly for me and not everybody.)


Rob

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
wrote in message news:OIEu5oVrHHA.3284@TK2MSFTNGP03.phx.gbl...
> There is no doubt that in comparaison of VB6/VBA, you need a lot of firing 
> power inside your machine to tame .NET but this is precisely what we are 
> in the process of getting this year as the basic configuration for a new 
> machine.
>
> As for a decent upgrading path from Access, this is probably something we 
> should see next year.  The SSMA-Access is already written in .NET, so I 
> won't be surprised if in one year or two there is a new version to upgrade 
> not only the backend to SQL-Server but also the frontend to .NET (and of 
> course with the option of upgrading only the FE, without touching the BE).
>
> -- 
> Sylvain Lafontaine, ing.
> MVP - Technologies Virtual-PC
> E-mail: sylvain aei ca (fill the blanks, no spam please)
>
>
> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
> news:%23IT9SGSrHHA.4324@TK2MSFTNGP04.phx.gbl...
>> Yeah, okay, for the type of issues you're talking about, I can see .NET 
>> being more useful.  Last time I tried it, though, it was unacceptably 
>> slow, and until someone can prove to me that the speed is now more 
>> acceptable--which I've heard for 2005--and that there's a decent upgrade 
>> path from VB6 (or better yet Access)--which I've never heard from 
>> anybody--it won't ever be on my list of things to upgrade to.
>>
>>
>>
>> Rob
>>
>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
>> wrote in message news:eIy$dlLrHHA.532@TK2MSFTNGP06.phx.gbl...
>>> Yeah, even me can get emphatic about something, sometime.  It's only 
>>> that in this case (ADP), I got tired to hear people coming here to say 
>>> that even if they know nothing about SQL-Server, ADP or .NET - from 
>>> their own admission and they are proud of it, too - they will now tell 
>>> us everything we need to know about these.
>>>
>>> As to VB6, I agree with you that on many occasions, it will be faster 
>>> than .NET.  The problem here is not the performance when you are doing 
>>> old stuff like 10 years ago; the problem is when you want to have new 
>>> stuff. When was the last time that you have used some kind of datagrid 
>>> control with VB6 and that you didn't have the taste of eating your own 
>>> keyboard after a few days of work?
>>>
>>> Something as simple as having rows of different colors can put VB6 or 
>>> Access down to their knees and I won't speak here about stuff like 
>>> having images or adding an unbound control to a continuous form or even 
>>> something very basic like keeping the multi-rows selection active when 
>>> the user click on a button.
>>>
>>> When you need to add some extensibility of any kind, VB6/Access are 
>>> simply not the way to go.
>>>
>>> -- 
>>> Sylvain Lafontaine, ing.
>>> MVP - Technologies Virtual-PC
>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>
>>>
>>> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
>>> news:%238b%23c$TqHHA.1168@TK2MSFTNGP03.phx.gbl...
>>>> I'm surprised you're so emphatic about this, Sylvain.  That's not like 
>>>> you, from what I've seen.
>>>>
>>>> I have to go with Baz on this one.  Many, MANY people are moving away 
>>>> from the .NET framework (Delphi seems to be a popular choice) because 
>>>> VS 2002/2003 were very slow, and while VS 2005 offers some 
>>>> improvements, I gather, it's still often sluggish when using managed 
>>>> code, and many VB6 developers have no interest in learning C++ as the 
>>>> only unmanaged alternative.  And, of course, there's the nightmare of 
>>>> having to redistribute the megalith that is the Framework itself.
>>>>
>>>> As for how fast it will eventually be on upcoming OS's/hardware, 
>>>> designing a system for stuff that's not out yet isn't usually the best 
>>>> idea, as people have to use this stuff today on their current OS and 
>>>> hardware, not a year or two (or more) from now.  I'm also a firm 
>>>> believer that the hardware shouldn't have to compensate for the 
>>>> underlying speed of the application.
>>>>
>>>> I completely disagree that VB6 with COM/DCOM/ActiveX would be a "black 
>>>> hole".  Most tests have shown that in fact, it's significantly faster 
>>>> than .NET in most cases.  There are certainly some tests where .NET 
>>>> outperforms VB6, and it's a lot more capable in some areas like 
>>>> multithreading, but most of the articles I've read have put VB6 as 
>>>> 1.5 - 2x faster than the equivalent .NET code.
>>>>
>>>> But regardless of any of that, even if VS 2005 works faster in any 
>>>> given scenario, Access is still VBA-based, and as such, you'd still be 
>>>> using COM, etc.  *If* you're going to use Access, which many people 
>>>> still prefer to .NET solutions, it makes sense that you'd supplement it 
>>>> with VB6/COM if necessary, rather than using .NET and having to go 
>>>> through Interop.
>>>>
>>>> I will agree that it looks like VB6 is likely to die eventually, and 
>>>> unfortunately, Microsoft seems to have no understanding of why people 
>>>> are complaining about that fact.  An unmanaged version of VB with 
>>>> greater backwards compatibility has been suggested, and requested by 
>>>> thousands (http://classicvb.org/Petition/), but again, it seems 
>>>> unlikely. Nevertheless, VB6 continues to be supported on Vista, at 
>>>> least in some fashion, so I don't really see much of a problem 
>>>> continuing to use that for the time being.
>>>>
>>>> All that said, if .NET is fast enough for you (and as I say, I gather 
>>>> 2005 made improvements in that area), then certainly there's a lot to 
>>>> be said for it in terms of enterprise development, Internet 
>>>> development, etc.  So, as they say, "if it works, don't knock it."  For 
>>>> myself, however, the sluggishness was intolerable, and at least so far, 
>>>> I'm sticking with VB6 DLLs to back up my Access projects where 
>>>> necessary.
>>>>
>>>>
>>>> Rob
>>>>
>>>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
>>>> wrote in message news:%23m5jYhTqHHA.3372@TK2MSFTNGP03.phx.gbl...
>>>>> Where you should start?  Well, you should start with VB6, VC6, 
>>>>> COM/DCOM/MTS, ActiveX and the registries base themselves!
>>>>>
>>>>> In case you forgot, this whole system was already in the process of 
>>>>> imploding under its own weigth 10 years ago. Doing a program today is 
>>>>> no longer the process of aligning a few text boxes, comboboxes and 
>>>>> listboxes on a simple form, tabbed form or continuous form on an 
>>>>> isolated machine, without internet and maybe even without a LAN.
>>>>>
>>>>> Take a look at all the criticisms that were made about VB6, unmanaged 
>>>>> C++, the DLL hell, the total lack of security and the constant 
>>>>> corruption of the registries base - to name only that - and now think 
>>>>> about what would be the situation if instead of dumping that into the 
>>>>> garbage bin, MS would have increasing the size of these dinosaurs by a 
>>>>> factor of at least ten to one hundred.  Increasing the size of the 
>>>>> registry base by a factor of at least one hundred is not only a 
>>>>> reasonable assumption but it's quite likely a gross under-estimation 
>>>>> of the true space that would have been required to cover the actual 
>>>>> possibilities of the .NET framework using these old technologies.
>>>>>
>>>>> I agree with you that even on a Core 2 Duo, running the actual 
>>>>> Framework 2.0 is slow but if you would have tried to do the same thing 
>>>>> with COM/DCOM/ActiveX - as it was with VB6 - probably that not only 
>>>>> your machine will be running slow but probably that it would have 
>>>>> imploding into a black hole.
>>>>>
>>>>> Buying a dual core is now standard and they will soon be replaced with 
>>>>> quad core as the basic developer machine. (Probably that the price of 
>>>>> the quad core will be cut by two this autumn, if not before.). Next 
>>>>> year, you will start to see machines with 8 cores and from 16 to 32 
>>>>> Gigs of memory running Vista 64 bit as the basic machine bought by 
>>>>> most developers. With such power running in 2008, do you really think 
>>>>> that people wanted to keep VB6/VC6 - with a few more gugus here and 
>>>>> there - as their main developer tools?
>>>>>
>>>>> VB6 was the most popular tool in the past years?  So do were DBase3, 
>>>>> Lotus 1-2-3 and Word Perfect.  Now, all these tools are gone because 
>>>>> Ashton-Tate, Lotus and Word-Perfect Corporation were believing that 
>>>>> whence you have reached a market share of 90% and more, you don't have 
>>>>> to evolve anymore and your base of loyal users will remain with you 
>>>>> for eternity.
>>>>>
>>>>> -- 
>>>>> Sylvain Lafontaine, ing.
>>>>> MVP - Technologies Virtual-PC
>>>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>>>
>>>>>
>>>>> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
>>>>> news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
>>>>>> Where do I start?  How about the bloated, festering dotnet framework,
>>>>>> redolent as it is with the promise of versioning nightmares in years 
>>>>>> ahead?
>>>>>> How about not being able to write unmanaged code in anything but C++? 
>>>>>> How
>>>>>> about it being so damned slow?  How about the IDE being so damned 
>>>>>> awful?
>>>>>> How about MS's sheer, arrogant supidity in trying to kill the world's 
>>>>>> most
>>>>>> popular development tool (I refer of course to VB6) without even 
>>>>>> providing
>>>>>> backward compatibility?
>>>>>>
>>>>>> That's a few gripes about the big stuff, I could think of a lot more 
>>>>>> if I
>>>>>> tried.  There's LOADS more stuff at the small level, my favourite in
>>>>>> 2002/2003 was the godawful combo box which couldn't even do what a 
>>>>>> VB6 combo
>>>>>> could do, let alone an Access combo.  Sure, you can build your own 
>>>>>> controls,
>>>>>> which is exactly what I did to get a half-decent combo box (or you 
>>>>>> can buy
>>>>>> 'em if you didn't already think you'd wasted enough dosh on this 
>>>>>> garbage),
>>>>>> but that's what you have to do all the time: so much of it doesn't 
>>>>>> quite
>>>>>> work as you would expect or want that you spend all your damn time
>>>>>> finding/creating workarounds and alternatives.
>>>>>>
>>>>>> Yeeeuk!  I don't blame you for puffing this stuff - you've got a 
>>>>>> living to
>>>>>> make - but frankly it makes me ill.
>>>>>>
>>>>>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>>>>>>> I still don't know the reasons you were not satisfied with VS/.NET
>>>>>>> (except that with learning time)?
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Thomas
>>>>>>>
>>>>>>> -----------------------------------------
>>>>>>> NConstruct - Intelligent Software Factory
>>>>>>> http://www.nconstruct.com
>>>>>>> -----------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Baz wrote:
>>>>>>> > Yep, that sounds like advertising.  As I said, I own VS 2003
>>>>>> Professional
>>>>>>> > and I consider it to have been a complete waste of money.  I do 
>>>>>>> > not
>>>>>> believe
>>>>>>> > that VS 2005 can be so much better that it is worth me spending 
>>>>>>> > any time
>>>>>> on
>>>>>>> > it, and I'm certainly not going to waste any money buying add-ons 
>>>>>>> > for
>>>>>> it.
>>>>>>> > I'd rather put my efforts into continuing my investigations into 
>>>>>>> > Delphi
>>>>>> (not
>>>>>>> > that I see Delphi as a serious contender to Access either for 
>>>>>>> > database
>>>>>>> > applications, it's just that, for the odd occasion when I do 
>>>>>>> > something
>>>>>> for
>>>>>>> > which I don't consider Access suitable, I'd like to have a serious 
>>>>>>> > and
>>>>>>> > current alternative to VB6).
>>>>>>> >
>>>>>>> > "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>>>>>>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd party
>>>>>>> >> component if you don't want, and you can still produce i.e. 
>>>>>>> >> continuous
>>>>>>> >> forms with DataGridView component. This is not the best solution 
>>>>>>> >> but
>>>>>>> >> either is not worse than Access (for which there is no free 
>>>>>>> >> version at
>>>>>>> >> all).
>>>>>>> >>
>>>>>>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>>>>>>> >> Developer Express, ComponentOne, Infragistic etc. really produce 
>>>>>>> >> very
>>>>>>> >> usable products. Serious developer should at least try them 
>>>>>>> >> before
>>>>>> judge
>>>>>>> >> about their usability or quality. They are also very cheap 
>>>>>>> >> comparing to
>>>>>>> >> the price of developing only few percent of their features. Maybe 
>>>>>>> >> it
>>>>>>> >> sounds like advertising but I really just buy them and use them, 
>>>>>>> >> and I
>>>>>>> >> want to share good experience with other developers.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Regards,
>>>>>>> >> Thomas
>>>>>>> >>
>>>>>>> >> -----------------------------------------
>>>>>>> >> NConstruct - Intelligent Software Factory
>>>>>>> >> http://www.nconstruct.com
>>>>>>> >> -----------------------------------------
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Baz wrote:
>>>>>>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>>>>>>> >>> (having
>>>>>>> >>> wasted a significant amount of my own money on upgrading from VS 
>>>>>>> >>> 6 to
>>>>>> VS
>>>>>>> >>> 2002/2003, and then concluding that it sucked so badly that I 
>>>>>>> >>> was
>>>>>> simply
>>>>>>> > not
>>>>>>> >>> interested in using it).
>>>>>>> >>>
>>>>>>> >>> Nor am I impressed by a product which requires me to buy 
>>>>>>> >>> third-party
>>>>>>> > add-ons
>>>>>>> >>> in order for it to be anywhere near usable.
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>>>>>> >>>> Baz wrote:
>>>>>>> >>>>> I have two things to say to you: linked subforms and 
>>>>>>> >>>>> continuous
>>>>>> forms.
>>>>>>> >>>> Baz, I don't think this is an Access advantage. For example, 
>>>>>>> >>>> look at
>>>>>>> >>>> those tutorials:
>>>>>>> >>>>
>>>>>>> >
>>>>>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>>>>>> >
>>>>>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>>>>> >>>> It's fast to create (at least as fast as Access), it has more
>>>>>> features
>>>>>>> >>>> than Access etc.
>>>>>>> >>>>
>>>>>>> >>>> This is only one approach - it's similar to Access' one (I 
>>>>>>> >>>> don't like
>>>>>>> >>>> any of them, though). If you need n-tiered application it's 
>>>>>>> >>>> better to
>>>>>>> > do
>>>>>>> >>>> the dynamic grid creation. In both cases you can do it with VS 
>>>>>>> >>>> out of
>>>>>>> >>>> the box or you can buy some 3rd party components.
>>>>>>> >>>>
>>>>>>> >>>> -- 
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> Regards,
>>>>>>> >>>> Thomas
>>>>>>> >>>>
>>>>>>> >>>> -----------------------------------------
>>>>>>> >>>> NConstruct - Intelligent Software Factory
>>>>>>> >>>> http://www.nconstruct.com
>>>>>>> >>>> -----------------------------------------
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >
>>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


0
Robert
6/13/2007 1:41:40 AM
I must admit that there is a difference between an upgrade path and a decent 
upgrade path.  If I were the happy owner of MS, I would have put a little 
more money into this upgrading wizard but as I'm not, ...

-- 
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)


"Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
news:uMxEKwVrHHA.4624@TK2MSFTNGP06.phx.gbl...
> Ummm...have you ever used the VB6 to VB.NET "Upgrade" Wizard?  IIRC, it 
> doesn't upgrade forms at all, and it does a less-than-stellar job at 
> upgrading VB6 code.  I can't say I have confidence in MS to write 
> something that will upgrade my FE in a way that would be better than 
> simply starting from scratch.  (For me personally, my BE is already SQL 
> Server, so that's not an issue, though obviously that's strictly for me 
> and not everybody.)
>
>
> Rob
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
> wrote in message news:OIEu5oVrHHA.3284@TK2MSFTNGP03.phx.gbl...
>> There is no doubt that in comparaison of VB6/VBA, you need a lot of 
>> firing power inside your machine to tame .NET but this is precisely what 
>> we are in the process of getting this year as the basic configuration for 
>> a new machine.
>>
>> As for a decent upgrading path from Access, this is probably something we 
>> should see next year.  The SSMA-Access is already written in .NET, so I 
>> won't be surprised if in one year or two there is a new version to 
>> upgrade not only the backend to SQL-Server but also the frontend to .NET 
>> (and of course with the option of upgrading only the FE, without touching 
>> the BE).
>>
>> -- 
>> Sylvain Lafontaine, ing.
>> MVP - Technologies Virtual-PC
>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>
>>
>> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
>> news:%23IT9SGSrHHA.4324@TK2MSFTNGP04.phx.gbl...
>>> Yeah, okay, for the type of issues you're talking about, I can see .NET 
>>> being more useful.  Last time I tried it, though, it was unacceptably 
>>> slow, and until someone can prove to me that the speed is now more 
>>> acceptable--which I've heard for 2005--and that there's a decent upgrade 
>>> path from VB6 (or better yet Access)--which I've never heard from 
>>> anybody--it won't ever be on my list of things to upgrade to.
>>>
>>>
>>>
>>> Rob
>>>
>>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)> 
>>> wrote in message news:eIy$dlLrHHA.532@TK2MSFTNGP06.phx.gbl...
>>>> Yeah, even me can get emphatic about something, sometime.  It's only 
>>>> that in this case (ADP), I got tired to hear people coming here to say 
>>>> that even if they know nothing about SQL-Server, ADP or .NET - from 
>>>> their own admission and they are proud of it, too - they will now tell 
>>>> us everything we need to know about these.
>>>>
>>>> As to VB6, I agree with you that on many occasions, it will be faster 
>>>> than .NET.  The problem here is not the performance when you are doing 
>>>> old stuff like 10 years ago; the problem is when you want to have new 
>>>> stuff. When was the last time that you have used some kind of datagrid 
>>>> control with VB6 and that you didn't have the taste of eating your own 
>>>> keyboard after a few days of work?
>>>>
>>>> Something as simple as having rows of different colors can put VB6 or 
>>>> Access down to their knees and I won't speak here about stuff like 
>>>> having images or adding an unbound control to a continuous form or even 
>>>> something very basic like keeping the multi-rows selection active when 
>>>> the user click on a button.
>>>>
>>>> When you need to add some extensibility of any kind, VB6/Access are 
>>>> simply not the way to go.
>>>>
>>>> -- 
>>>> Sylvain Lafontaine, ing.
>>>> MVP - Technologies Virtual-PC
>>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>>
>>>>
>>>> "Robert Morley" <rmorley@magma.ca.N0.Freak1n.sparn> wrote in message 
>>>> news:%238b%23c$TqHHA.1168@TK2MSFTNGP03.phx.gbl...
>>>>> I'm surprised you're so emphatic about this, Sylvain.  That's not like 
>>>>> you, from what I've seen.
>>>>>
>>>>> I have to go with Baz on this one.  Many, MANY people are moving away 
>>>>> from the .NET framework (Delphi seems to be a popular choice) because 
>>>>> VS 2002/2003 were very slow, and while VS 2005 offers some 
>>>>> improvements, I gather, it's still often sluggish when using managed 
>>>>> code, and many VB6 developers have no interest in learning C++ as the 
>>>>> only unmanaged alternative.  And, of course, there's the nightmare of 
>>>>> having to redistribute the megalith that is the Framework itself.
>>>>>
>>>>> As for how fast it will eventually be on upcoming OS's/hardware, 
>>>>> designing a system for stuff that's not out yet isn't usually the best 
>>>>> idea, as people have to use this stuff today on their current OS and 
>>>>> hardware, not a year or two (or more) from now.  I'm also a firm 
>>>>> believer that the hardware shouldn't have to compensate for the 
>>>>> underlying speed of the application.
>>>>>
>>>>> I completely disagree that VB6 with COM/DCOM/ActiveX would be a "black 
>>>>> hole".  Most tests have shown that in fact, it's significantly faster 
>>>>> than .NET in most cases.  There are certainly some tests where .NET 
>>>>> outperforms VB6, and it's a lot more capable in some areas like 
>>>>> multithreading, but most of the articles I've read have put VB6 as 
>>>>> 1.5 - 2x faster than the equivalent .NET code.
>>>>>
>>>>> But regardless of any of that, even if VS 2005 works faster in any 
>>>>> given scenario, Access is still VBA-based, and as such, you'd still be 
>>>>> using COM, etc.  *If* you're going to use Access, which many people 
>>>>> still prefer to .NET solutions, it makes sense that you'd supplement 
>>>>> it with VB6/COM if necessary, rather than using .NET and having to go 
>>>>> through Interop.
>>>>>
>>>>> I will agree that it looks like VB6 is likely to die eventually, and 
>>>>> unfortunately, Microsoft seems to have no understanding of why people 
>>>>> are complaining about that fact.  An unmanaged version of VB with 
>>>>> greater backwards compatibility has been suggested, and requested by 
>>>>> thousands (http://classicvb.org/Petition/), but again, it seems 
>>>>> unlikely. Nevertheless, VB6 continues to be supported on Vista, at 
>>>>> least in some fashion, so I don't really see much of a problem 
>>>>> continuing to use that for the time being.
>>>>>
>>>>> All that said, if .NET is fast enough for you (and as I say, I gather 
>>>>> 2005 made improvements in that area), then certainly there's a lot to 
>>>>> be said for it in terms of enterprise development, Internet 
>>>>> development, etc.  So, as they say, "if it works, don't knock it." 
>>>>> For myself, however, the sluggishness was intolerable, and at least so 
>>>>> far, I'm sticking with VB6 DLLs to back up my Access projects where 
>>>>> necessary.
>>>>>
>>>>>
>>>>> Rob
>>>>>
>>>>> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam 
>>>>> please)> wrote in message 
>>>>> news:%23m5jYhTqHHA.3372@TK2MSFTNGP03.phx.gbl...
>>>>>> Where you should start?  Well, you should start with VB6, VC6, 
>>>>>> COM/DCOM/MTS, ActiveX and the registries base themselves!
>>>>>>
>>>>>> In case you forgot, this whole system was already in the process of 
>>>>>> imploding under its own weigth 10 years ago. Doing a program today is 
>>>>>> no longer the process of aligning a few text boxes, comboboxes and 
>>>>>> listboxes on a simple form, tabbed form or continuous form on an 
>>>>>> isolated machine, without internet and maybe even without a LAN.
>>>>>>
>>>>>> Take a look at all the criticisms that were made about VB6, unmanaged 
>>>>>> C++, the DLL hell, the total lack of security and the constant 
>>>>>> corruption of the registries base - to name only that - and now think 
>>>>>> about what would be the situation if instead of dumping that into the 
>>>>>> garbage bin, MS would have increasing the size of these dinosaurs by 
>>>>>> a factor of at least ten to one hundred.  Increasing the size of the 
>>>>>> registry base by a factor of at least one hundred is not only a 
>>>>>> reasonable assumption but it's quite likely a gross under-estimation 
>>>>>> of the true space that would have been required to cover the actual 
>>>>>> possibilities of the .NET framework using these old technologies.
>>>>>>
>>>>>> I agree with you that even on a Core 2 Duo, running the actual 
>>>>>> Framework 2.0 is slow but if you would have tried to do the same 
>>>>>> thing with COM/DCOM/ActiveX - as it was with VB6 - probably that not 
>>>>>> only your machine will be running slow but probably that it would 
>>>>>> have imploding into a black hole.
>>>>>>
>>>>>> Buying a dual core is now standard and they will soon be replaced 
>>>>>> with quad core as the basic developer machine. (Probably that the 
>>>>>> price of the quad core will be cut by two this autumn, if not 
>>>>>> before.). Next year, you will start to see machines with 8 cores and 
>>>>>> from 16 to 32 Gigs of memory running Vista 64 bit as the basic 
>>>>>> machine bought by most developers. With such power running in 2008, 
>>>>>> do you really think that people wanted to keep VB6/VC6 - with a few 
>>>>>> more gugus here and there - as their main developer tools?
>>>>>>
>>>>>> VB6 was the most popular tool in the past years?  So do were DBase3, 
>>>>>> Lotus 1-2-3 and Word Perfect.  Now, all these tools are gone because 
>>>>>> Ashton-Tate, Lotus and Word-Perfect Corporation were believing that 
>>>>>> whence you have reached a market share of 90% and more, you don't 
>>>>>> have to evolve anymore and your base of loyal users will remain with 
>>>>>> you for eternity.
>>>>>>
>>>>>> -- 
>>>>>> Sylvain Lafontaine, ing.
>>>>>> MVP - Technologies Virtual-PC
>>>>>> E-mail: sylvain aei ca (fill the blanks, no spam please)
>>>>>>
>>>>>>
>>>>>> "Baz" <bazz@REMOVEbcap.THEeuro1net.CAPScom> wrote in message 
>>>>>> news:4667c87d$0$30323$fa0fcedb@news.zen.co.uk...
>>>>>>> Where do I start?  How about the bloated, festering dotnet 
>>>>>>> framework,
>>>>>>> redolent as it is with the promise of versioning nightmares in years 
>>>>>>> ahead?
>>>>>>> How about not being able to write unmanaged code in anything but 
>>>>>>> C++? How
>>>>>>> about it being so damned slow?  How about the IDE being so damned 
>>>>>>> awful?
>>>>>>> How about MS's sheer, arrogant supidity in trying to kill the 
>>>>>>> world's most
>>>>>>> popular development tool (I refer of course to VB6) without even 
>>>>>>> providing
>>>>>>> backward compatibility?
>>>>>>>
>>>>>>> That's a few gripes about the big stuff, I could think of a lot more 
>>>>>>> if I
>>>>>>> tried.  There's LOADS more stuff at the small level, my favourite in
>>>>>>> 2002/2003 was the godawful combo box which couldn't even do what a 
>>>>>>> VB6 combo
>>>>>>> could do, let alone an Access combo.  Sure, you can build your own 
>>>>>>> controls,
>>>>>>> which is exactly what I did to get a half-decent combo box (or you 
>>>>>>> can buy
>>>>>>> 'em if you didn't already think you'd wasted enough dosh on this 
>>>>>>> garbage),
>>>>>>> but that's what you have to do all the time: so much of it doesn't 
>>>>>>> quite
>>>>>>> work as you would expect or want that you spend all your damn time
>>>>>>> finding/creating workarounds and alternatives.
>>>>>>>
>>>>>>> Yeeeuk!  I don't blame you for puffing this stuff - you've got a 
>>>>>>> living to
>>>>>>> make - but frankly it makes me ill.
>>>>>>>
>>>>>>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>>> news:Ofdcl7EqHHA.3312@TK2MSFTNGP05.phx.gbl...
>>>>>>>> I still don't know the reasons you were not satisfied with VS/.NET
>>>>>>>> (except that with learning time)?
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> -----------------------------------------
>>>>>>>> NConstruct - Intelligent Software Factory
>>>>>>>> http://www.nconstruct.com
>>>>>>>> -----------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Baz wrote:
>>>>>>>> > Yep, that sounds like advertising.  As I said, I own VS 2003
>>>>>>> Professional
>>>>>>>> > and I consider it to have been a complete waste of money.  I do 
>>>>>>>> > not
>>>>>>> believe
>>>>>>>> > that VS 2005 can be so much better that it is worth me spending 
>>>>>>>> > any time
>>>>>>> on
>>>>>>>> > it, and I'm certainly not going to waste any money buying add-ons 
>>>>>>>> > for
>>>>>>> it.
>>>>>>>> > I'd rather put my efforts into continuing my investigations into 
>>>>>>>> > Delphi
>>>>>>> (not
>>>>>>>> > that I see Delphi as a serious contender to Access either for 
>>>>>>>> > database
>>>>>>>> > applications, it's just that, for the odd occasion when I do 
>>>>>>>> > something
>>>>>>> for
>>>>>>>> > which I don't consider Access suitable, I'd like to have a 
>>>>>>>> > serious and
>>>>>>>> > current alternative to VB6).
>>>>>>>> >
>>>>>>>> > "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>>>> > news:%23NkiVxDqHHA.208@TK2MSFTNGP05.phx.gbl...
>>>>>>>> >> Baz, you can use free VS 2005 Express and don't buy any 3rd 
>>>>>>>> >> party
>>>>>>>> >> component if you don't want, and you can still produce i.e. 
>>>>>>>> >> continuous
>>>>>>>> >> forms with DataGridView component. This is not the best solution 
>>>>>>>> >> but
>>>>>>>> >> either is not worse than Access (for which there is no free 
>>>>>>>> >> version at
>>>>>>>> >> all).
>>>>>>>> >>
>>>>>>>> >> IMO, a lot of 3rd party components *do* work very well - guys at
>>>>>>>> >> Developer Express, ComponentOne, Infragistic etc. really produce 
>>>>>>>> >> very
>>>>>>>> >> usable products. Serious developer should at least try them 
>>>>>>>> >> before
>>>>>>> judge
>>>>>>>> >> about their usability or quality. They are also very cheap 
>>>>>>>> >> comparing to
>>>>>>>> >> the price of developing only few percent of their features. 
>>>>>>>> >> Maybe it
>>>>>>>> >> sounds like advertising but I really just buy them and use them, 
>>>>>>>> >> and I
>>>>>>>> >> want to share good experience with other developers.
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> Regards,
>>>>>>>> >> Thomas
>>>>>>>> >>
>>>>>>>> >> -----------------------------------------
>>>>>>>> >> NConstruct - Intelligent Software Factory
>>>>>>>> >> http://www.nconstruct.com
>>>>>>>> >> -----------------------------------------
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> Baz wrote:
>>>>>>>> >>> Well I haven't got VS 2005 and I'm not likely to get it either 
>>>>>>>> >>> (having
>>>>>>>> >>> wasted a significant amount of my own money on upgrading from 
>>>>>>>> >>> VS 6 to
>>>>>>> VS
>>>>>>>> >>> 2002/2003, and then concluding that it sucked so badly that I 
>>>>>>>> >>> was
>>>>>>> simply
>>>>>>>> > not
>>>>>>>> >>> interested in using it).
>>>>>>>> >>>
>>>>>>>> >>> Nor am I impressed by a product which requires me to buy 
>>>>>>>> >>> third-party
>>>>>>>> > add-ons
>>>>>>>> >>> in order for it to be anywhere near usable.
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> "Thomas" <thomas@nconstruct.com> wrote in message
>>>>>>>> >>> news:%23DnhRDCqHHA.4608@TK2MSFTNGP02.phx.gbl...
>>>>>>>> >>>> Baz wrote:
>>>>>>>> >>>>> I have two things to say to you: linked subforms and 
>>>>>>>> >>>>> continuous
>>>>>>> forms.
>>>>>>>> >>>> Baz, I don't think this is an Access advantage. For example, 
>>>>>>>> >>>> look at
>>>>>>>> >>>> those tutorials:
>>>>>>>> >>>>
>>>>>>>> >
>>>>>>> http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Smart_Client/DataGridView.htm
>>>>>>>> >
>>>>>>> http://www.devexpress.com/Products/NET/WinForms/XtraGrid/tutorials/lesson1/xtragridlesson1.html
>>>>>>>> >>>> It's fast to create (at least as fast as Access), it has more
>>>>>>> features
>>>>>>>> >>>> than Access etc.
>>>>>>>> >>>>
>>>>>>>> >>>> This is only one approach - it's similar to Access' one (I 
>>>>>>>> >>>> don't like
>>>>>>>> >>>> any of them, though). If you need n-tiered application it's 
>>>>>>>> >>>> better to
>>>>>>>> > do
>>>>>>>> >>>> the dynamic grid creation. In both cases you can do it with VS 
>>>>>>>> >>>> out of
>>>>>>>> >>>> the box or you can buy some 3rd party components.
>>>>>>>> >>>>
>>>>>>>> >>>> -- 
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> Regards,
>>>>>>>> >>>> Thomas
>>>>>>>> >>>>
>>>>>>>> >>>> -----------------------------------------
>>>>>>>> >>>> NConstruct - Intelligent Software Factory
>>>>>>>> >>>> http://www.nconstruct.com
>>>>>>>> >>>> -----------------------------------------
>>>>>>>> >>>>
>>>>>>>> >>>
>>>>>>>> >
>>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 


0
Sylvain
6/13/2007 3:44:53 AM
Sylvain Lafontaine wrote:
> I must admit that there is a difference between an upgrade path and a decent 
> upgrade path.  If I were the happy owner of MS, I would have put a little 
> more money into this upgrading wizard but as I'm not, ...
> 
There is a decent upgrade path from C to C#. MS put
a lot of time and effort into making sure that a VS C
project could be ported to VS.Net without tears.


I think it's like Vatican watching, or China watching as was. You see 
the effects of the decisions that are made by some hidden process, and 
then you get to work back from there and speculate about cause, and 
speculate about possible future actions.
0
DAVID
6/14/2007 3:59:44 AM
Reply:

Similar Artilces:

DotNet plug-in
Hi there, Does anyone have experience in developing add-ins for the Store Op and wanna to share their experience ? I have coded a simple add-in under VS.net and as when I go the Store Manager's Addin menu to select the addin, the system complains that no application was found. any insights will be appreciated thank you, -Chris On Thu, 9 Dec 2004 10:19:19 -0800, "Chris" <dont@have.one> wrote: >I have coded a simple add-in under VS.net and >as when I go the Store Manager's Addin menu >to select the addin, the system complains that >no application was f...

Forms 05-23-07
I need help with creating a form in Access that when you check the check box the form moves to the next page and the next page check boxes are blank. I have created a test for my boss for a class and every time I check the box for the correct answer and go to the next page the checked boxes goes onto the next page. I also wanted to know if there is a way just to have a single page with the questions and answers on it and when you check it you can just move to the next questions. Please help I am desperate. "anget24" <u34467@uwe> wrote in message news:729f0cd9dcaca@uwe... >...

linking two forms
I have two tables: Table 1 stores the primary key, Protocol#, along with details about the protocol. Table 2 stores additional information that will apply to SOME of hte protocols. It has no primary key, but is linked to table 1 through Protocol#. Problem: Form 1 is where I enter details into Table 1. I'd like to enter information into Table 2 using a separate form (not a subform), Form 2, which I can access from Form 1 using a button. I set the VBA code to open Form 2 as follows: Dim stDocName As String Dim stLinkCriteria As String stDocName = "FRM_2" st...

Window Mail Windows 7
I started a new folder and now want to delete it but am unable to. Any suggestions? Please reply to bswanson2@roadrunner.com Where in Windows Live Mail did you create that folder? When you=20 right-click on that folder, isn't 'Delete' one of the options? Sorry, we don't provide individual support via email here. --=20 Gary VanderMolen, Microsoft MVP (Mail) Microsoft MVP program: http://mvp.support.microsoft.com "Bob Swanson" <bswanson2@roadrunner.com> wrote in message = news:CC9B137E-F049-4D24-99EC-5BC141822BB0@microsoft.com... >I star...

My IE8 32 bit in Windows 7 (64 bit) fails to execute hyperlinks sometimes
Sometimes clicking on hypertext links in the subject environment (windows7 64 bit, ie8*32 appears to do nothing, although each click adds an additional iexplore*32 process to the task manager. These processes persist until terminated in task manager. Any clue as to how to troubleshoot/repair? steve What anti-virus application or security suite is installed and is your subscription current? What anti-spyware applications (other than Defender)? What third-party firewall (if any)? Has a(another) Norton or McAfee application ever been installed on the computer (e.g., a...

Force Redraw of Main POS window from Custom Button Popup
I'm implemented a form that's presented when the POS user presses a Custom Button. The form can if necessary update items in the Transaction, this works fine. The only issue is that while my form is displayed the Transaction window will not update to reflect the changes made by my code. When I close my form the Transaction window updates and properly displays the changes I've made. I'm looking for a way to force the Transaction window to refresh before returning from my Custom Button form. Any help would be greatly appreciated. Regards, Tom No way to force it programmatical...

OWA Failed Process Creates Blank Window @ Windows Login
A user's computer does the following: Every time after logging into his Windows XP computer, a Security Alert window pops up indicating that: Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the site's security certificate. .... Do you want to proceed? Yes, No, View certificate This started happening after a failed logon attempt to OWA. The security alert popup that precedes the OWA login occurs with all of my users; it is annoying but harmless and that is not the problem that I am trying to correct at the moment. ...

IDBE Ribbon Creator for Access 2007 ribbon customization
Anybody else using this product? I've been very pleased with it. I have created several complex ribbons with good results. My question: It appears to be a one-use tool. That is to say, you need to complete your ribbon design in its entirety before you start adding code to open forms, reports, etc. Because if you don't, if you modify the ribbon design and import it back into your Access database, you lose whatever code you added to basRibbonCallbacks for openining your own forms, reports, etc. I've been tinkering with the XML to modify the ribbon after the first imp...

If No Records in Subform, Parent Form Record doesn't display
If I don't have any records in a subform, the record in the parent form doesn't display on my main form. The record is in the underlying table for the parent form, so I don't understand what the problem is. I'm sure the solution is simple and I'll kick myself later. Thanks for the help! -- Thanks. "Melissa" <Melissa@discussions.microsoft.com> wrote in message news:21CC91F1-D0EF-4ECF-9CBB-D5B19CB684D8@microsoft.com... > If I don't have any records in a subform, the record in the parent form > doesn't display on my main form. ...

Calling the Immediate Window
I handle dozens of DBs for various offices in my organization. The biggest hurdle I face is when I have to update data for these back-ends, someone somewhere invariably has the DB open. I have a Master DB that I use to automate all the updating I have to do and have incorporated the "WhoIsInTheDatabaseLockFile" procedure to find the Machine Names of these users (none of these DBs use user-level security - I inherited them as is). I then have some code to open a cmd window and run the psloggedon.exe from SysInternals (now part of Microsoft) to get the actual username of the per...

How to remove config for a missing NIC in Windows Server 2003.
Does any one know how to remove the configuration (IP address, netmask, default gateway, etc) for a network adapter that has been removed from a Windows server /after/ the physical NIC has been removed? I ran in to this recently after a p2v conversion when I went to re-configure the IP settings on the virtual adapter. In doing so, I got a pop-up saying that the same IP address (etc) was still configured on an adapter that had been removed from the system. I was able to find the information in the registry and remove it so that Windows would not prompt, but I don't think ...

Form Headers
!@#$%^&*()?! I am soooo frustrated. It seems like a simple enough function. I just want to have the header print on each form page. The help states that in the properties there is a Repeat to set to Yes. I have double clicked, clicked, right clicked on every section and box and cannot find this command. Please help. There is such capability with REPORTS. I don't believe there is any such capability when printing FORMS. John Spencer Access MVP 2002-2005, 2007-2010 The Hilltop Institute University of Maryland Baltimore County Evon wrote: > !@#$%^&*...

Highest Version of Adobe Reader for Windows 98se
Hi, Can someone tell me what is the highest version of Adobe Reader I can use on my Windows 98se computer? Thank You in Advance, John PS, Remove "ine" from my email address On 05/08/2010 06:34 AM, jaugustine@verizon.net wrote: > Hi, > > Can someone tell me what is the highest version of Adobe Reader I can > use on my Windows 98se computer? > > Thank You in Advance, John > > PS, Remove "ine" from my email address > Adobe is very bloated you will probably be better off with Foxit it'...

Embedding image in Entity form
Hello, Is it possible to embedd and image in the entity forms (without using an iframe)? For example, we have different opportunity types. If it's type A then we want to display one image, if it's type B then we show a different image. Thanks for the help! Well, technically Yes, you need to do some AJAX with on the form onLoad event. If you have experience with inserting and manipulating html using javascript, then you can look into it. Otherwise, I would suggest go with the iFrame route. :) Darren Liu, Microsoft CRM MVP http://www.crowecrm.com On Nov 7, 7:01 am, MDV1457 <M...

Unhide the Application Window
I have vba code in an Access program that calls and manipulates data in an Excel spreadsheet. All the manipulation code works fine. This spreadsheet is unsecured (by design) and can be viewed by anyone. The problem is that after my code works on the file, the next time it is opened (not by any code) the application is hidden and the user must go to the menu bar and manually unhide the window. Is there code to rectify this situation? *****Posted via: http://www.ozgrid.com Excel Templates, Training & Add-ins. Free Excel Forum & Business Software***** This is a guess. If your users...

Windows live safety scanner
I am running windows vista home premium and IExplorer 8 ..I have used the windows live safety scanner many times in the last year..The last couple of times I tried running it I got the following message We're sorry. This version of the Windows Live OneCare safety scanner doesn't work with your Web browser or operating system. It goes on to say that I need to have windows vista and internet explorer...any ideas why this could be happening?? "Mike Naughton" <mrmickeyjr@yahoo.com> wrote in message news:EE6B628B-21A5-4CFD-A5E8-8397852C6FFE@microsoft.com...

Integrated Windows authentication OWA and Exchange active sync
I have found that Win 98, NT and VPN clients can not access OWA without turning off integrated windows a authentication in the security settings of the exchange virtual directory in the default website of IIS. That was really not a big deal for me until a bunch if execs signed a new cell phone contract and showed up with tre650's wanting to get e-mail on their phone (nothing like good technology planning). The treo650 is a palmOS-based smartphone and is capable of syncing calendar and phone info via exchange active sync. Of course it did not work straight out of the box. I came across a ...

Tasks in Calender Window
Is there any way to have my tasks display in the calender view just as my appointments do? thanks. In Outlok 2003, select the following from the menu: View | Arrange By | current view | day/week/month with autopreview "Sharif T. Karim" <shariftk@gmail.com> wrote in message news:1160003510.747053.317010@m73g2000cwd.googlegroups.com... > Is there any way to have my tasks display in the calender view just as > my appointments do? thanks. > Not quite relevant ZootRot as that makes the Notes Field show for Calendar Items but has nothing to do with Tasks. To sho...

Automating a Form and it's Tracking sheet
Hello, I have a project that I have been working on and I need to try to automate a few of the general tasks. I have not used Excel before and do not know the limits or capabilities, so I am asking for some help. I had to make an Excel spreadsheet "Service Request" form for people in our "company" to fill out and submit back to us. My Boss would then have to authorize it or not. Once it was authorized, my group would then give it a sequential number and then save it to a shared file. The general information, from the form, is then put into a separate tracking worksheet. T...

Sudden appearance of Windows installer window
I use Money2002. Until today 12/15/05 all was fine. Now when I open or move between functions I get miscellaneous Installer windows that then disappear. They do not appear to affect any functionality but are irksome. Last night I did accept automatic Windows Updates and I don't know if there was anything there that would cause this. After the updates ran I did do a restart. Any suggestions? Hi Karen, I had that problem with Mny 03. My problem was that one of my junk file cleaning programs was deleting a .bak file. That particular file must have been necessary for Mny 03 to ...

Outlook with Windows ME
I can't delete e-mails in the "sent" file, Won't respond to delete button on tool bar, if I right click, I see the delete option but e-mail won't delete. I set up a sub-folder, I can transfer the file from "sent" to the sub-folder, then I can delete it to the Deleted folder. Is this just another "ME" issue ?? My "sent" file get's bigger every day.....HELP What version of Outlook? Have you tried creating a new personal folders file, making that one the default and then going into the sent items in the old .pst file and then deleti...

Excel VB Windows XP and 2000 problem
Hi, i have writen some macros using office 2000 on windows XP and they wor well. Then i changed my Operating system to windows 2000 and installe the same office 2000. When i try to open my excel sheet with both macros enabled and disable Visiual Basic gives me the "file not found" error in a message box and nothing more and didnt open the file. what could be the reason? any idea? i didnt intentially use any dl from XP but dont know if VB uses them by default! thanks in advance.. i can provide the excel sheet if anyone want to review... please let m know. Emr -- Message posted ...

MDI application run as a Child window
Hi, I do have a MDI application working properly. I have to include this into a plugin that would be loaded by a second application. In the second application my MDI application should run properly. Does somebody have any ideea where is the beginning? Any link is welcome! I have tried to include the MDI app into a dll and ocx with no success. TIA, Valentin What you want to do is not what MFC doc/view apps were designed for. You are probably looking for some sort of ActiveX control. Its been a while since I did this, but you could have a MFC app inside another container (DocObjectCont...

Windows XP IMAPI interfaces
hi every one I need help in using windows xp IMAPI (CD Burning) interface through MFC I need to know how to construct IStorage Object to use the IMAPI to add data to cd session regards Hesham I gave up doing that specific step for the same reason. I worked around it by using the SHGetFolderPath (?) api to locate the staging folder and just copy the files there then burn. The copy to this location amounts to the same thing. See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shgetfolderpath.asp "Hesham Desouky" <...

Subtracting value from main form
I have a borrow module which will alow user to return item separately. So, I have get the structure of returning it separately. In my main form is the borrowing item, with the loaned quantity and the owed quantity (will be calculated). In the subform, there is the returning transaction. User will need to key in the quantity returned and it will be automatically deducted from the quantity owed. But how am I supposed to get the quantity deducted while it 1 is in main form and the other is in subform? -- Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/Forums.aspx/access-fo...