A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

dotnet windows forms vs. Access



 
 
Thread Tools Display Modes
  #21  
Old June 3rd, 2007, 09:34 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Fred Boer
external usenet poster
 
Posts: 314
Default dotnet windows forms vs. Access

....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" wrote in message
...
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) ?



  #22  
Old June 3rd, 2007, 10:20 PM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
John W. Vinson
external usenet poster
 
Posts: 18,261
Default dotnet windows forms vs. Access

On Sun, 3 Jun 2007 16:34:07 -0400, "Fred Boer"
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]
  #23  
Old June 4th, 2007, 12:13 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Tore
external usenet poster
 
Posts: 2
Default dotnet windows forms vs. Access


"PMK" wrote in message
news
On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" wrote:

I have done a lot of Access clients to SQL Server and find it very
powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.


Tore,

Can you give me a few examples?

Peter


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




  #24  
Old June 4th, 2007, 12:52 AM posted to microsoft.public.access
(PeteCresswell)
external usenet poster
 
Posts: 438
Default dotnet windows forms vs. Access

Per To
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
  #25  
Old June 4th, 2007, 03:13 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Robert Morley
external usenet poster
 
Posts: 113
Default dotnet windows forms vs. Access

That sounds like something Bush would say. :-)


Rob

"Fred Boer" wrote in message
...
...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" wrote in message
...
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) ?





  #26  
Old June 4th, 2007, 07:38 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Baz
external usenet poster
 
Posts: 380
Default dotnet windows forms vs. Access


"PMK" wrote in message
...
On Sun, 3 Jun 2007 09:42:06 +0100, "Baz"
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?


  #27  
Old June 4th, 2007, 07:42 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
Baz
external usenet poster
 
Posts: 380
Default dotnet windows forms vs. Access

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" wrote in message
...
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




  #28  
Old June 4th, 2007, 09:28 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Mon, 4 Jun 2007 01:13:37 +0200, "Tore" wrote:


"PMK" wrote in message
news
On Sun, 3 Jun 2007 11:22:43 +0200, "Tore" wrote:

I have done a lot of Access clients to SQL Server and find it very
powerful.
Here are some pros and cons:

Vs.net provides a lot more functionality for windows clients than access.
Therefore it is also more complicated to learn and use. If you do not need
the extra functionality compared access, then access could be your choice.


Tore,

Can you give me a few examples?



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
  #29  
Old June 4th, 2007, 10:27 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Mon, 4 Jun 2007 07:38:55 +0100, "Baz"
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
  #30  
Old June 4th, 2007, 10:57 AM posted to microsoft.public.vstudio.general,microsoft.public.access,microsoft.public.access.adp.sqlserver
PMK
external usenet poster
 
Posts: 10
Default dotnet windows forms vs. Access

On Sun, 3 Jun 2007 08:21:41 -0700, "Norman Yuan"
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
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 06:19 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.