Access w/unbound forms/client-server vs .NET: anybody tried both?
(Pete Cresswell)
starting to sound plausible that the manhours spent doing an MS Access front end
with unbound forms and client-server back end may be close to a wash against the
same project done in .NET windows.
A guy that I mentored through Access development for several years is working on
the .NET project and he claims that he can get a .NET/window screen up and
running "just about as fast" as he can get an MS Access unbound screen working.
I know that, personally, I invest quite a bit of time/code in managing my
unbound forms. It seems like much of that would go away using .NET
windows/controls bound to .NET/XML/Datagrams - at least enough to outweigh
Access's less labor-intensive controls (like the text box with it's
automatically-generated/bound label or the combo/list box's AfterUpdate events).
And, since C/S would be a "given" it seems like writing the stored procedures
would also be a wash.
Anybody tried it both ways?
-----------------------
PeteCresswell
Steve Jorgensen
that Access with unbound forms gives little advantage. The fact that you can
make .NET base class forms and inherit/extend them makes .NET a potential major
time saver down the road. The only obvious place where Access still shines with
unbound forms is the awesome combo and listbox controls.
Also, have you thought about the reports issue? I watched someone try to work
with reports in .NET, and although they look very powerful, the interface is
really, really frustrating, and the object model is byzantine.
Albert D. Kallal
make sense at all in ms-access. I also believe that there is LITTLE
performance advantage.
For sure, if you actually try and use un-bound forms in ms-access, you will
actually wind up doing MORE WORK then what occurs in VB (I not talking about
.net yet..but I will later on here.
The reason why VB is better then ms-access in un-bound forms is that VB was
DESIGNED that way. In other words all of the tools in VB are sharpened with
a very good knife edge to make forms that are un-bound. Thus, in VB you have
a good number of data controls that you drop on to the screen. You then
connect all controls to those data controls (it is not bad, but not near
what we have in ms-access). However, this approach does take a lot more work
then our bound controls. Further, you don't get the HUGE NUMBER of events
and control over the data like you do in ms-access (on current, before
update, after update, on insert..you know the list..and it is huge).
So, ms-access does not work very well when you use un-bound forms for data
entry. And, I don't know why one would. (it is just a bad idea). Why do
this?
Now, what about the productivity issues here? One of the REALLY important
aspects of development in software has been the rise of object orientated
programming. It is barely only 10 years old for the "main" stream
development platforms.
Like any tool, the more advanced the tool becomes, the more training and
skill is required to REALLY benefit from that tool. However, once the skill
level is attained, THEN ONLY one can reap the additional benefits of using
that tool.
For example, VB forms are really very simple as compared to the increate
feature rich forms that we have in ms-access. However, unless one takes time
to learn, and use the ms-access forms, then little benefit is derived from
all those extra complex features.
Going from ms-access forms to VB forms is a exercise in utter
disappointment. Those VB forms do nothing, and are like dry lake as compared
to the rich vibrant ocean of features and plant life that ms-access forms
are!
Now, the issue productivity and rate of development speed is going to vary
depending on many aspects of the development tools used. I have OFTEN stated
that ms-access runs circles around VB when it comes to development speed.
This is still the case.
In terms of ease of use, and "power" most will tell you the following from
"hard" to easy in terms of difficulty for platforms are:
C++
Delphi
Visual FoxPro (??? don't know where it goes!)
ms-access/VBA
VB
Notice how I have ms-access higher then VB (of course ms-access is harder
then VB..vb is really simple!).
Notice that once you are beyond ms-access, then ALL of the above tools are
OO (object orientated)
Why is OO important here?
Well, ok lets assume we are now developing applications in Visual FoxPro in
place of ms-access. Of course right away, I am going to miss the "where"
clause that we have in ms-access. The where clause in ms-access is one those
"fabulous" features. It allows me to place a button on a continues sub form
that will launch open a corresponding form to display details. Amazingly,
ms-access does this with ONE LINE OF CODE. I am sure we have done something
like:
docmd.OpenFrom "frmMoreDetials",,,"id = " & me.id
The above of course is ms-access at it's best. VB is crap to do the above.
Now, what the heck does a developer do in these other languages?
Well, in VB I suppose each time a new form is created, the developer COULD
drop IN some code to "add" the where clause feature to the code, but having
to do that EACH TIME is a royal pain. We could probably also write some
class object to "open" the form, but then that is just too much code each
time!
However, in a OO environment, all we do is add the "where" feature to the
base form object that we use for the whole application. So, in a OO
environment, now every form that I create will have a "where" clause built
in (that is because we have inheritance in OO). However, to take advantage
of this fact, YOU THE designer of the application better realize that having
a "where" clause for each form is a good idea (so, more design skills are
needed here). So, as your skills progress, you will often see a LOT of
things that need to be added to each form you make.
For example, if you every looked at many of my screen shots, you will see
that I always display:
Access logon user name
Computer workstation name
NetworkLogon name.
Once again, a object approach means that I can add the above properties to
the "base" form object. Now each new form I create in my application will
have those features.
Since most developers don't think of adding a "where" clause, or most
developers don't need the above things like "logon name", computer name etc,
then a OO approach is NOT going to help. However, over time as you want MORE
AND MORE features, then OO starts to make sense.
So, the real advantage of OO is that OVER TIME your efforts mean that each
additional application you write means that you base forms and objects will
also have MORE FEATURES.
So, clearly, adoption of OO ideas and concepts should be a goal of all
developers.
Ok, having said all of the above, this now brings us to .net.
VB.net is a true OO environment. It means as a developer OVER TIME as I add
more features to my appcltions, then I can REALLY start to increase my
productivity as a developer. One could over time conceptuality even reach
the same level of productivity that we now enjoy in ms-access.
Hence, we seeing the begging of OO being adopted as a main stream
development methodology. In the 1970's it was structured programming. In the
80's it was the introduction of the pc and the start of client/server ideas.
By the early 90's we started to see the introduction OLE, and COM objects.
This does not necessarily mean OO, but the real thing was inter-program
communications via com.
Now, we seeing the even the mainstream development tools going OO. As each
of the above "changes" happened, many developers failed to make the next
step. I am not saying that we access developers need to make the OO
leap..but it is starting to make sense.
Now that the arch rival to ms-access has gone OO, then we might just have to
start looking at this!
The .net tools are getting very high grades from developers, and it is
enabling them to create more software for a given amount of time. At the end
of the day...more software for a given amount of time will win the day.
After all, that is why we all use ms-access.
A .net version of ms-access would not be such a bad thing!
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
kal...@msn.com
http://www.attcanada.net/~kallal.msn
David W. Fenton
<6d9Aa.66677$3C2.2...@news3.calgary.shaw.ca>:
>Well, I certainly believe that using un-bound forms for data entry
>does not make sense at all in ms-access. I also believe that there
>is LITTLE performance advantage.
I've never heard anyone claim that they did unbound forms in Access
for performance reasons. These are the reasons I know of:
1. greater control over when data gets saved.
2. greater control of locking, which means:
3. reduced concurrency problems.
Unbound forms are appropriate where you want to minimize the number
of locks.
The disadvantage is the loss of a whole lot of properties/events,
like .Dirty and .OnCurrent. It can be worked around with custom
properties and lots of extra code, but it's still a pain.
The loading and saving of the unbound data is really the trivial
part. The easiest way to do it is to have the control names be
exactly the same as the names of the fields they are "unbound" to,
so you can use a loop of the recordset's .Fields collection to
load, and a similar loop to test for changed fields and update the
data. It really is a piece of cake.
It's all the rest of it that is hard!
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Steve Jorgensen
I would add to this that I've suddenly started to increase my productivity in
Access itself by finding ways to use bound forms for things I used to think were
best done with unbound forms. For instance, I just created a design pattern and
set of supporting procedures for a form to add a new record to a table in
response to a NotInList event. A single, generic function is called from the
NotInList handler with the name of the form to add the new row and the NewData
parameter, and an optional ExtraData parameter. The function eventually returns
a value for the Result event handler's parameter. Even error handling is fully
encapsulated in the function.
By putting in a lot of work up front to create a template, bound form for adding
a single new row and meeting all the requirements of my function, I can now
create custom forms of this ilk simply by copying the form, changing the
rowsource, changing the Controlsource of the txtNewData control (a disabled
textbox), and dragging any additional needed controls onto the form - that's it,
it's done. It's amazing to think how many years I've been meticulously
hand-building the code and forms for every single instance of this need and have
been doing unnecessary work to make the forms unbound as well since that seemed
like the easiest way to have control over when the record is saved and make sure
only one record can be added.
My template form includes code and property settings ensure that exactly one
record can be added, the form can only be "closed" by clicking OK or Cancel
(actually made invisible so the handler function can continue and read the
Response property before closing it), the form's public Response property
variable will be set appropriately when the user clicks OK or Cancel, and the
record will be saved if and only if the user selects OK.
I never thought of doing this before because, when implenting a single case, the
simplest approach is the unbound form, but once the work has been done once to
figure out how to do it with a bound form, and the design has been optimized to
reduce the number of changes required to create a new case from a copy of the
template, most of the code is moved out into stand-alone modules, etc., then you
never have to deal with it again. Any improvements made to the template over
time become a benefit to all subsequent projects.
Relevant to this thread, notice how the above scheme is designed to take
advantage of the strengths and patterns of Access, the tool it's built on, and
work at the highest possible abstraction levels provided by the tool. In the
process, it gains the benefit of the abstractions provided by the Access
form/object models so that, for instance, no changes are required to make this
work in an ADP. Using the unbound form, changes would have to be made.
Steve
Fenton) wrote:
>I've never heard anyone claim that they did unbound forms in Access
>for performance reasons. These are the reasons I know of:
>
>1. greater control over when data gets saved.
>
>2. greater control of locking, which means:
>
>3. reduced concurrency problems.
>
<snip>
I am not sure how you defining performance, but all of the above
impacts performance in a multi-user system... at least from a user's
perspective.
Anyone who feels that there system requires unbound forms for data
entry, need to consider if Access is the most appropriate tool.
Steven
Paul
> Well, I certainly believe that using un-bound forms for data entry
> does not make sense at all in ms-access. I also believe that there is
> A .net version of ms-access would not be such a bad thing!
Aggreed. Most reasons for home-brew binding in Access
are history anyway: newer versions expose the form's
recordset - speaking of OO.
(Pete Cresswell)
>The only obvious place where Access still shines with
>unbound forms is the awesome combo and listbox controls.
I *still* can't figure out why nobody's come out with VB lookalikes...two pages
of code just to autoscroll...geeze!
>Also, have you thought about the reports issue? I watched someone try to work
>with reports in .NET, and although they look very powerful, the interface is
>really, really frustrating, and the object model is byzantine.
I may be able to report on that sometime in the next year. The application
that the .NET project is replacing is mine. I'm back on board at the company
as a sort of SME vis-a-vis the old app.
I'm currently reverse-engineering requirements specs from about 50 of the
original app's MS Access reports, TB implemented via Crystal Reports. Some
guy on the IT side is currently campaigning to get me designated as one of the
people who replicates those reports via Crystal.
If that happens, it should be an interesting experience - because I've often
wondered about the tradeoffs between the two products. One person who posted
here said they thought MS Access reporting was really good but that the later
versions of Crystal were even better.
-----------------------
PeteCresswell
(Pete Cresswell)
>So, ms-access does not work very well when you use un-bound forms for data
>entry. And, I don't know why one would. (it is just a bad idea). Why do
>this?
Actually, it works well for me and I like it. I suspect that more people can
beat on the DB that way and if somebody pulls the plug on their PC, there's less
chance of corruption. But what I really like is the total control....
I sort of lied about the "unbound" part. What I really do is create a work DB
in C:\TEMP and populate work tables in it which all my forms are bound to.
Conceptually, it seems to be quite like .NET is doing: you grab the data; cut
the cord; work on it; and then reestablish the connection and blow it back to
the back end at "Save" time.
Makes for a fairly robust application, since a given user is only "in" the back
end for hundredths of a second at a time.
It's also pretty easy once you get the conceptual model really wired. But it
*does* take more coding and what got my attention in .NET was the notion of just
makeing a connection, getting the data, and then disconnecting until it's time
to save....but without the extra coding/work tables/queries and so-forth.
-----------------------
PeteCresswell
(Pete Cresswell)
>Anyone who feels that there system requires unbound forms for data
>entry, need to consider if Access is the most appropriate tool.
To-date, my primary reason for using MS Access is speed of development. A few
years ago, I asked myself what I really was - based on the development efforts
that I judged I'd had the most success and happiest clients in...and came up
with the idea that I'm the guy you call when you need an application up and
running within a few months or even weeks and IT can't deliver it for more like
a year or two.
When things were slow, I re-coded one of my MS Access apps using VB6. My
experience was that it takes about 3 times the manhours to do the same app in
VB6 as it does to do it in MS Access. Don't understimate the time savings of
MS Access queries, textbox controls that have pre-aligned labels, subforms, and
the MS Access report writer. I've heard estimates from other people that the
factor is as high as five.
One guy I know (who is has more IQ points that me and my entire family put
together) opined that he could do an app in VB about as fast as in Access - but
he'd never actually done it.... so I'm sticking with the factor of three for MS
Access vs VB6....
Excluding the aforementioned possibilities of .NET, that makes MS Access the
only game in town for me - bound or unbound....
-----------------------
PeteCresswell
David W. Fenton
<ctf2dv06o3d5kf9jo...@4ax.com>:
>Relevant to this thread, notice how the above scheme is designed
>to take advantage of the strengths and patterns of Access, the
>tool it's built on, and work at the highest possible abstraction
>levels provided by the tool. In the process, it gains the benefit
>of the abstractions provided by the Access form/object models so
>that, for instance, no changes are required to make this work in
>an ADP. Using the unbound form, changes would have to be made.
While I'm glad you're happy with this "discovery," I can't imagine
what the big deal is! I've never used unbound forms for that
purpose and tend to have generic forms for it. Of course, for the
most part, I disallow adding new items to dropdown lists, as the
mainline data entry people aren't allowed to do that. Where they
*are* allowed, it is often with multi-attribute entities, like
companies or customers, and in that case, there really is no
generic solution, and the ADD NEW process for adding that entity is
no different than the ADD NEW process of adding the entity when
*not* trying to choose it from the dropdown list.
While I'm not huge fan of unbound forms for data entry/editing,
they do have their place. I'm firmly convinced that my largest app
would completely crash and burn if the main data entry process did
not use an unbound form, because the amount of additions at one
time tends to become very high at times when the client is busiest.
I invested a lot of time in creating that unbound form.
Another time I invested a lot of time (and money; Hi, Larry!) in
creating an unbound form was where I had three large tables that
would hardly ever be edited (they were imported from an outside
source) and I didn't want to do the work of creating three big
unwieldy forms for viewing editing that data. So, instead, I
created a custom unbound form that loaded each field into a row of
a listbox (using a listbox callback function wrapped around an
array), and when a row was selected, you could edit that row with
controls at the top of the listbox. It was a lot of work to create,
but much easier to maintain than the three forms it replaced would
have been. Given that it was going to be used very seldom, I really
didn't want to spend the time and effort in created a form that had
everything on it. It would also have been very hard to understand
and use (in addition to being a pain to maintain).
But I can't say I use unbound forms for data editing very often.
I do, however, use them all the time for dialogs and QBF interfaces
and a whole host of other uses.
David W. Fenton
<3ed145dc...@news.westnet.com>:
>On Sun, 25 May 2003 21:20:57 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
>>I've never heard anyone claim that they did unbound forms in
>>Access for performance reasons. These are the reasons I know of:
>>
>>1. greater control over when data gets saved.
>>
>>2. greater control of locking, which means:
>>
>>3. reduced concurrency problems.
>
><snip>
>
>I am not sure how you defining performance, but all of the above
>impacts performance in a multi-user system... at least from a
>user's perspective.
It *impacts* performance, but it may or may not speed up the
processes. It may make it possible to do things that would
otherwise not be possible (such as supporting 20 people doing data
entry at once instead of just 5 or 10), but that's not, strictly
speaking, speeding up the performance of the operations the unbound
form is doing (in comparison to the bound form).
>Anyone who feels that there system requires unbound forms for data
>entry, need to consider if Access is the most appropriate tool.
Well, I don't make categorical statements about this. It depends on
the application and the requirements. In some cases, concurrency
may be vastly improved with an unbound application. Alternatives
might be switching your back end to a server database engine, but
that would also require significant re-engineering, and because of
the need to manage connections carefully, might very well lead you
to implement unbound forms, anyway.
I can't believe *I'm* the one defending unbound forms here!
I definitely agree that they should be the exception rather than
the rule, and there should be very specific and necessary reasons
for implementing them.
But I don't think they automatically indicate that something is
wrong with your design or that you are trying to use the wrong
tool.
Albert D. Kallal
>
> I can't believe *I'm* the one defending unbound forms here!
> I definitely agree that they should be the exception rather than
> the rule, and there should be very specific and necessary reasons
> for implementing them.
>
> But I don't think they automatically indicate that something is
> wrong with your design or that you are trying to use the wrong
> tool.
I think you were quite clear here. In other words, to *just* focus on
the bound vs un-bound form issue here is really a bit too narrow of
a point on my part. Further , it in fact is not that much work to
create un-bound forms is ms-access, especially after a few times
it has been done.
So, there are some reasons to use un-bound forms for data entry, but
certainly the prevailed view among some DB and VB types is that
un-bound forms ARE THE ONLY way to develop good client/server
appcltions is also totally un-fair.
Bound access forms are just fine in a client server environment. However,
there is no real wrong in creating some un-bound data entry forms in access
either.
I was the one kind of shooting un-bound forms here, and that is not really
fair on my part. That issue alone is not why ms-access is such a great tool.
Larry Linson
> I can't believe *I'm* the one defen-
> ding unbound forms here!
<CHUCKLE!>
> I definitely agree that they should
> be the exception rather than the
> rule, and there should be very
> specific and necessary reasons
> for implementing them.
I concur, absolutely.
> But I don't think they automatically
> indicate that something is wrong
> with your design or that you are
> trying to use the wrong tool.
But those who say that they always, and exclusively, use unbound forms raise
a question in my mind. I'd concede that Peter Miller, with code he's
developed, tested, and reused over the years, may not pay the kind of price
that we normally expect. But, I'd say that somewhere along the line, he
expended time and effort reimplementing functionality that Access provides.
I've not seen the source of any of Peter's work, but I have seen the source
of a number of developers who thought they routinely _had_ to use unbound
forms, or that it was _better_ to routinely use unbound forms and I can't
think of a single case where they were correct.
I've seen some applications with just a few unbound forms sprinkled in among
many, many bound forms, where each use of an unbound form was appropriate...
it's just another one of those things which needs to be used judiciously,
with good business judgement. But, IMNSHO, "few and far between" is the
operative phrase.
Larry Linson
> Installation with .Net is certainly more
> of a PITA then Access or VB, but
> it's not all that bad.
Whoa! Wasn't that part of the advertising super-hyper-hype about .NET...
XCOPY installs and the end of .DLL Hell forever?
Does this mean the Mighty Microsoft Marketing Machine scored again? <G>
Steve Jorgensen
>nos...@nospam.nospam (Steve Jorgensen) wrote in
><ctf2dv06o3d5kf9jo...@4ax.com>:
>
>>Relevant to this thread, notice how the above scheme is designed
>>to take advantage of the strengths and patterns of Access, the
>>tool it's built on, and work at the highest possible abstraction
>>levels provided by the tool. In the process, it gains the benefit
>>of the abstractions provided by the Access form/object models so
>>that, for instance, no changes are required to make this work in
>>an ADP. Using the unbound form, changes would have to be made.
>
>While I'm glad you're happy with this "discovery," I can't imagine
>what the big deal is! I've never used unbound forms for that
>purpose and tend to have generic forms for it. Of course, for the
>most part, I disallow adding new items to dropdown lists, as the
>mainline data entry people aren't allowed to do that. Where they
>*are* allowed, it is often with multi-attribute entities, like
>companies or customers, and in that case, there really is no
>generic solution, and the ADD NEW process for adding that entity is
>no different than the ADD NEW process of adding the entity when
>*not* trying to choose it from the dropdown list.
Well, I didn't think I was the first person to come up with using a bound form
for this. I guess my real excitement is in getting a better handle on how
design patterns like this one, not just reusable function libraries) can be used
to improve productivity. Yeah, I get that the part I'm excited about isn't
really what this thread is about.
>While I'm not huge fan of unbound forms for data entry/editing,
>they do have their place. I'm firmly convinced that my largest app
>would completely crash and burn if the main data entry process did
>not use an unbound form, because the amount of additions at one
>time tends to become very high at times when the client is busiest.
>I invested a lot of time in creating that unbound form.
How does an unbound form help this app? Are you queueing up entries and posting
them to the db tables in batches?
>Another time I invested a lot of time (and money; Hi, Larry!) in
>creating an unbound form was where I had three large tables that
>would hardly ever be edited (they were imported from an outside
>source) and I didn't want to do the work of creating three big
>unwieldy forms for viewing editing that data. So, instead, I
>created a custom unbound form that loaded each field into a row of
>a listbox (using a listbox callback function wrapped around an
>array), and when a row was selected, you could edit that row with
>controls at the top of the listbox. It was a lot of work to create,
>but much easier to maintain than the three forms it replaced would
>have been. Given that it was going to be used very seldom, I really
>didn't want to spend the time and effort in created a form that had
>everything on it. It would also have been very hard to understand
>and use (in addition to being a pain to maintain).
Neat - a universal table editor form (so long as there are no lookup fields, of
course).
>But I can't say I use unbound forms for data editing very often.
>
>I do, however, use them all the time for dialogs and QBF interfaces
>and a whole host of other uses.
App navigation is another really common use.
Steve Jorgensen
...
>I can't believe *I'm* the one defending unbound forms here!
>
>I definitely agree that they should be the exception rather than
>the rule, and there should be very specific and necessary reasons
>for implementing them.
>
>But I don't think they automatically indicate that something is
>wrong with your design or that you are trying to use the wrong
>tool.
I think, if you find that you have valid cause to make an app out of
predominantly unbound forms, though, that truly may indicate that Access is the
wrong tool.
Bill Ehrreich
This is a bit of a tangential point, but I use ASP.NET with MS Access
in cases where concurrent users are high but total data storage
requirements are not so high to justify going to a more industrial
strength database. ASP.NET gives extremely good performance, manages
your connections to the database and allows Access applications to be
run over WANs or the web. Also, I have enough code already written in
.NET that I would say that it takes me only 25% to 50% longer to
develop the web application than it would to develop an Access bound
approach (a useless approach in these scenarios). Of course, you have
all of the same object oriented advantages in ASP.NET as you would
with a .NET windows form application.
Bill Ehrreich
Hollywood, FL
(Pete Cresswell)
>ASP.NET gives extremely good performance, manages
>your connections to the database and allows Access applications to be
>run over WANs or the web. Also, I have enough code already written in
>.NET that I would say that it takes me only 25% to 50% longer to
>develop the web application than it would to develop an Access bound
>approach (a useless approach in these scenarios). Of course, you have
>all of the same object oriented advantages in ASP.NET as you would
>with a .NET windows form application.
Thanks. That's the kind of info I was trolling for.
IMHO, 50% more manhours isn't going to be significant to my big corporate
clients - so that makes ASP a real contender.
In fact, a project management/time recording system that I'm in the home stretch
on is probably about to become a candidate for something like that. The
manager I did it for is not pushing it out to other managers for evaluation and
more people seem to be coming on board. To me, this makes it inevitable that
somebody along the line will require that the timesheet portion be accessible
from people's home PC's. I *was* thinking Citrex for this aspect, but the
more I think about it, the more it seems like a copout on my part.
-----------------------
PeteCresswell
Steven R. Zuch
"David W. Fenton" <dXXXf...@bway.net> wrote in message
news:9386DAF3Bdf...@24.168.128.90...
> st...@nospam.com (Steve) wrote in
> <3ed145dc...@news.westnet.com>:
>
> >On Sun, 25 May 2003 21:20:57 GMT, dXXXf...@bway.net (David W.
> >Fenton) wrote:
> >
> >>I've never heard anyone claim that they did unbound forms in
> >>Access for performance reasons. These are the reasons I know of:
> >>
> >>1. greater control over when data gets saved.
> >>
> >>2. greater control of locking, which means:
> >>
> >>3. reduced concurrency problems.
> >
> ><snip>
> >
> >I am not sure how you defining performance, but all of the above
> >impacts performance in a multi-user system... at least from a
> >user's perspective.
>
> It *impacts* performance, but it may or may not speed up the
> processes. It may make it possible to do things that would
> otherwise not be possible (such as supporting 20 people doing data
> entry at once instead of just 5 or 10), but that's not, strictly
> speaking, speeding up the performance of the operations the unbound
> form is doing (in comparison to the bound form).
>
Unbound forms can improve performance. And that is clearly my point. As
you confirm "it may or may not speed up the process" ... to the extent it
speeds up the process it is improving performance.
Most applications just don't die when they reach a certain number of
concurrent users. Performance slows down due to the concurrency and other
problems. Unbound forms may help solve that problem.
> >Anyone who feels that there system requires unbound forms for data
> >entry, need to consider if Access is the most appropriate tool.
>
> Well, I don't make categorical statements about this. It depends on
> the application and the requirements.
That is why I used the word "consider". A need to use unbound forms MAY be
a warning that Access is not be the an appropriate tool.
If the developer is fighting with their development tool, spending more time
finding work arround the typical uses, then that tool may not be appropriate
for the task at hand.
>In some cases, concurrency
> may be vastly improved with an unbound application. Alternatives
> might be switching your back end to a server database engine, but
> that would also require significant re-engineering, and because of
> the need to manage connections carefully, might very well lead you
> to implement unbound forms, anyway.
>
> I can't believe *I'm* the one defending unbound forms here!
>
On the contrary, I felt that I was defending the use of unbound forms :)
> I definitely agree that they should be the exception rather than
> the rule, and there should be very specific and necessary reasons
> for implementing them.
>
> But I don't think they automatically indicate that something is
> wrong with your design or that you are trying to use the wrong
> tool.
>
Nothing is automatic nor certain. But it could be a warning. And that was
my point.
In summary, unbound forms can improve performance in certain situations, but
if your application requires a substantial use of unbound forms, other
development tools may be an more appropriate tool.
Steven
Brent Wheeler
"(Pete Cresswell)" <x@y.z> wrote in message
news:0312dvs5caviphhub...@4ax.com...
HTH
Brent Wheeler MVP
Larry Linson
> http://www.mvps.org/access/
>
> HTH
> Brent Wheeler MVP
Since real MVPs don't use non-specific links as answers as Don P Mellon
claimed, he has to impersonate an MVP to try to support his erroneous claim
that they do. As he did here.
David W. Fenton
>On Mon, 26 May 2003 00:24:41 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
>>While I'm not huge fan of unbound forms for data entry/editing,
>>they do have their place. I'm firmly convinced that my largest
>>app would completely crash and burn if the main data entry
>>process did not use an unbound form, because the amount of
>>additions at one time tends to become very high at times when the
>>client is busiest. I invested a lot of time in creating that
>>unbound form.
>
>How does an unbound form help this app? Are you queueing up
>entries and posting them to the db tables in batches?
No. First off, the records are fairly short, so lots of them fit on
a single data page. Instead of locking the record (i.e., data page
-- I don't think record-level locking is worth it) for the whole
time between the creation of the record and the save of the new
record, it creates the new record, saves it and returns the PK to
the unbound form, in one quick operation. The user enters the data
and it is saved during one quick operation.
There have been *no* collisions during that.
Now, to be fair, edit/write locks were not happening with the bound
form, but performance was *extremely* slow. The unbound form
happened to speed that up because it released a lot of the overhead
that in this instance happened to be slowing things down.
This is an all Jet application, BTW. If it were C/S, there wouldn't
be an issue here.
>>Another time I invested a lot of time (and money; Hi, Larry!) in
>>creating an unbound form was where I had three large tables that
>>would hardly ever be edited (they were imported from an outside
>>source) and I didn't want to do the work of creating three big
>>unwieldy forms for viewing editing that data. So, instead, I
>>created a custom unbound form that loaded each field into a row
>>of a listbox (using a listbox callback function wrapped around an
>>array), and when a row was selected, you could edit that row with
>>controls at the top of the listbox. It was a lot of work to
>>create, but much easier to maintain than the three forms it
>>replaced would have been. Given that it was going to be used very
>>seldom, I really didn't want to spend the time and effort in
>>created a form that had everything on it. It would also have been
>>very hard to understand and use (in addition to being a pain to
>>maintain).
>
>Neat - a universal table editor form (so long as there are no
>lookup fields, of course).
Right. It did involve creating a mapping table for user-friendly
descriptions of the fields and data types, etc., to make it
possible to know what to do with validation in the editing
controls, but it worked *really* well.
>>But I can't say I use unbound forms for data editing very often.
>>
>>I do, however, use them all the time for dialogs and QBF
>>interfaces and a whole host of other uses.
>
>App navigation is another really common use.
Yes. Counting all the dialogs, menus and the like, I probably have
as many unbound forms in my apps as bound! Or, it's a pretty even
match. Wow, just checked the app with the high usage issues (my
first example above), and there are 38 unbound forms, 2 bound main
forms and 17 bound subforms. So, that's twice as many unbound as
bound forms! But only *one* of the unbound forms is actually used
for data editing. Another major app has 37 unbound and 44 bound
forms, and none of the unbound forms are used for data editing.
Now, lots of my forms are what I think of as "semi-bound," meaning
one or a limited number of records loaded at a time (i.e., the
recordsource returns zero records until the user has chosen a
subset of one or more records to load). In the app with only two
bound main forms, both of them are "semi-bound," and in the other
app, the five main data entry forms are all "semi-bound."
"Semi-bound" forms are *not* the way the Access help files,
documentation and sample files encourage you to build applications.
Of course, neither is unbound, but for most applications,
"semi-bound" is the right way to do things, C/S or not.
David W. Fenton
Well, I think put another way: if you're doing most of your data
editing with unbound forms, then you're using the wrong tool or you
haven't a frigging clue how Access works.
Steve Jorgensen
I wonder where the bottleneck was with the bound form, then. If it's not
holding locks during edit/entry, then what's slowing it down? Is it the extra
round trip to increment/retrieve the Autonumber key, perhaps? Is that increment
a heavy collision point since all new added records must increment it? I assume
things like default values and validation rules are cached when the recordset is
opened, and don't get re-read for each new record?
I know Oracle has sequence objects used similarly to Autonumber keys in Access,
but not tied directly to a table columns. One neat feature of these objects is
that they can snag a whole series of numbers at once (configurable in size) so
contention is reduced. I guess a similar scheme could be done in Access, and
this might be worth an experiment, but a good test would require access to a LAN
with a large number of workstations to bang on the back end, measure performace,
and count locking errors.
Proposed experiment:
For a heavy data-entry table, change the Autonumber key to a plain old Long.
Add a new table with one row and one numeric field initially set to the next
available key in the data entry table. Write a function that uses a static
recordset on the key table with locking set to Edited Record to grab the next
available key value, add 10 to the saved value, then return the 10 values in
sequence each time it is called until it runs out and has to hit the recordset
again. Set the BeforeUpdate handler on the data entry form to get the new key
value by calling the function described above if the record is new.
Steve
Fenton) wrote:
<snip>
>Well, I think put another way: if you're doing most of your data
>editing with unbound forms, then you're using the wrong tool or you
>haven't a frigging clue how Access works.
>
It seems to me that you are very adverse to the use of unbound forms.
How do you then reconcile your statement above to your response to my
previous statement:
Steve:
"Anyone who feels that there system requires unbound forms for data
entry, need to consider if Access is the most appropriate tool."
David
"Well, I don't make categorical statements about this. It depends on
the application and the requirements. In some cases, concurrency
may be vastly improved with an unbound application. Alternatives
might be switching your back end to a server database engine, but
that would also require significant re-engineering, and because of
the need to manage connections carefully, might very well lead you
to implement unbound forms, anyway."
Will the real David please stand up ....
Steven
Steve Jorgensen
>On Mon, 26 May 2003 21:20:46 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
><snip>
>
>>Well, I think put another way: if you're doing most of your data
>>editing with unbound forms, then you're using the wrong tool or you
>>haven't a frigging clue how Access works.
>>
>
>It seems to me that you are very adverse to the use of unbound forms.
>How do you then reconcile your statement above to your response to my
>previous statement:
What David and I are saying is that there's nothing wrong with using unbound
forms occasionally for interacting with data and frequently for navigation,
dialogs, or other purposes, but if you intend to write an application in which
the idea is to -avoid- using bound forms for entering or editing data for some
reason, then Access might not make sense for you.
Bill Ehrreich
I posted this response yesterday through DevDex and it never got
through. I'll try again.
>>In fact, a project management/time recording system that I'm in the
home stretch on is probably about to become a candidate for something
like that. <<
By coincidence, I recently developed a corporate project/resource
management application for Citrix (the company itself is a customer of
mine) using MS Access. The application is used by their project
managers worldwide. Normally I would use ASP.NET for the user
interface in such cases, but because this was Citrix and their entire
corporate network is based on the Metaframe (of course), I thought
that I would try that approach. After all, sending screens and keys
over the WAN shouldn't be very different from sending HTML, right?
Wrong! Many users in offices overseas were experiencing huge lag and
wait times just to open the application, often when they were the sole
user. Citrix has tried to reduce the lag by moving the application to
servers with lower loads but the performance is still what I would
call unacceptable. I still regret designing the application all in
Access for the Metaframe. I told them that the next application I do
for them would use a web interface. Also, after that experience, I
question whether I would ever recommend using Citrix Metaframe for any
new applications when creating a web interface is an option.
Bill
Steve
<nos...@nospam.nospam> wrote:
>What David and I are saying is that there's nothing wrong with using unbound
>forms occasionally for interacting with data and frequently for navigation,
>dialogs, or other purposes, but if you intend to write an application in which
>the idea is to -avoid- using bound forms for entering or editing data for some
>reason, then Access might not make sense for you.
Thats exactly what I said several posts before, but such comment was
met with criticism. Maybe some people like to argue just for the sake
of it.
Steven
David W. Fenton
I don't know what the exact bottleneck was. But re-engineering it
unbound took care of it.
I don't think it *should* have been the AutoNumber thing, as Jet
3.x took care of that (in comparison to Jet 2.x, where the next
record could not be added until the currently edited new record had
been saved), but it could be that there are still issues there with
it.
>I know Oracle has sequence objects used similarly to Autonumber
>keys in Access, but not tied directly to a table columns. One
>neat feature of these objects is that they can snag a whole series
>of numbers at once (configurable in size) so contention is
>reduced. I guess a similar scheme could be done in Access, and
>this might be worth an experiment, but a good test would require
>access to a LAN with a large number of workstations to bang on the
>back end, measure performace, and count locking errors.
>
>Proposed experiment:
>For a heavy data-entry table, change the Autonumber key to a plain
>old Long. Add a new table with one row and one numeric field
>initially set to the next available key in the data entry table.
>Write a function that uses a static recordset on the key table
>with locking set to Edited Record to grab the next available key
>value, add 10 to the saved value, then return the 10 values in
>sequence each time it is called until it runs out and has to hit
>the recordset again. Set the BeforeUpdate handler on the data
>entry form to get the new key value by calling the function
>described above if the record is new.
Well, I don't know how you'd manage to prevent someone else from
grabbing your original value+1, then creating their own set of 10,
with duplicates on 9 of them.
In another sense, you just move the problem do a different place,
away from your identity field's inherent limitations (if that's
where the problem is in my case) to the difficulties of locking to
prevent duplicates.
One change to your experiment:
What if you started with Max() + 10 (call that N), then added
records N-9, N-8, N-7, etc., until your 10th record would re-use
the already existing record number N. That way, anyone hitting the
table after you'd inserted N would get N + 10 and could not
overlap.
It would mean that you'd have to have a branch in your code that
updates an existing record when your key = N, instead of inserting
the record, but, hey, it means you don't have to have complicated
code to avoid another user overlapping the number space.
David W. Fenton
<3ed2b4b4...@news.westnet.com>:
>On Mon, 26 May 2003 21:20:46 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
><snip>
>
>>Well, I think put another way: if you're doing most of your data
>>editing with unbound forms, then you're using the wrong tool or
>>you haven't a frigging clue how Access works.
>
>It seems to me that you are very adverse to the use of unbound
>forms. . . .
No, not at all. As I said, some of my apps have more unbound forms
than bound.
I do believe that using an unbound form for editing probably is a
bad idea in most cases, and should be done only when there's a very
strong justification for doing so.
> . . . How do you then reconcile your statement above to your
>response to my previous statement:
>
>Steve:
>
>"Anyone who feels that there system requires unbound forms for
>data entry, need to consider if Access is the most appropriate
>tool."
>
>"Well, I don't make categorical statements about this. It depends
>on the application and the requirements. In some cases,
>concurrency may be vastly improved with an unbound application.
>Alternatives might be switching your back end to a server database
>engine, but that would also require significant re-engineering,
>and because of the need to manage connections carefully, might
>very well lead you to implement unbound forms, anyway."
>
>Will the real David please stand up ....
Well, the statement "if you're doing most of your data editing with
unbound forms" is hardly a categorical. It's a conditional, and
it's based on a ratio of unbound to bound forms used for editing,
not any kind of absolute numbers.
Perhaps you don't understand the word "categorical."
Lyle Fairfield
news:3ed39c54....@news.westnet.com:
Here in CDMA? Surely not!
--
Lyle
Steve Jorgensen
I'm not sure I've fully communicated the idea. I'm suggesting that there is a
separate table with a single row/field that is used as a counter for the next
available (not reserved) key value for the new data table. Max() would only be
used once to initialize value for this table after converting the key from
Autonumber to Long. Each session would edit the key value record using a
pessemistic ock, read the next available key value, and write back the value +
10 (or however many values are being reserved for use by the session), then save
the record.
A brief pessemistic record lock on that table is required, but contention levels
could be made arbitrarily low just by increasing the number of values reserved
each time.
David W. Fenton
<3ed39c54....@news.westnet.com>:
I didn't get that from what you wrote at all. I got a blanket
condemnation of unbound forms.
Steve
Fenton) wrote:
>Well, the statement "if you're doing most of your data editing with
>unbound forms" is hardly a categorical. It's a conditional, and
>it's based on a ratio of unbound to bound forms used for editing,
>not any kind of absolute numbers.
>
>Perhaps you don't understand the word "categorical."
David, re-read the post. It was YOU who used the word categorical to
MY statement:
"Anyone who feels that their system requires unbound forms for
data entry, need to consider if Access is the most appropriate
tool."
Your statement was just a slight variation from mine. You were being
hypocritical calling mine categorical. You criticize a comment and
then come write back and repeat it.
Steven
(Pete Cresswell)
> Citrix has tried to reduce the lag by moving the application to
>servers with lower loads but the performance is still what I would
>call unacceptable. I still regret designing the application all in
>Access for the Metaframe. I told them that the next application I do
>for them would use a web interface. Also, after that experience, I
>question whether I would ever recommend using Citrix Metaframe for any
>new applications when creating a web interface is an option.
Thanks...you may have saved my client a bunch of manhours and me from having egg
on my face... It's ASP or Windows.NET for sure for this thing then...
I don't know diddley about ASP.NET or HTML, but it seems to me like this
particular screen (a time entry screen) should be straightforward enough for me
to farm it out to somebody in the client's department who has that kind of
experience.
Biggest source of complexity is the pivot-style presentation...i.e. taking a
table whose rows are hours worked and date and flipping it into one row per
project/week. But that's already being done by stored procedures and all the
HTML page has to do is feed the server a pay week, present the results, let the
user edit same, and blow it all back to the server.
-----------------------
PeteCresswell
JD Kronicz
I read you email. Interesting thoughts ... I have been thinking along
the same lines (i.e. what is my niche etc.) I do most of my
developement in Access also. I have been trying to pick up VS.net.
Main drive is to improve my applications in a number of ways (internet
access being one primary consideration) but I too am wondering whether
I can do the same things I do with access in anywhere near the time in
VS.net. I am hoping that as my proficieny increases my efficiency
will allow me to develope apps in VS.net in roughly the time it takes
me to develope in Access. Although I am worried that what you say may
be true.
JD
"(Pete Cresswell)" <x@y.z> wrote in message news:<37n2dvsn5q76cke4e...@4ax.com>...
> RE/
> >Anyone who feels that there system requires unbound forms for data
> >entry, need to consider if Access is the most appropriate tool.
>
> To-date, my primary reason for using MS Access is speed of development. A few
> years ago, I asked myself what I really was - based on the development efforts
> that I judged I'd had the most success and happiest clients in...and came up
> with the idea that I'm the guy you call when you need an application up and
> running within a few months or even weeks and IT can't deliver it for more like
> a year or two.
>
> When things were slow, I re-coded one of my MS Access apps using VB6. My
> experience was that it takes about 3 times the manhours to do the same app in
> VB6 as it does to do it in MS Access. Don't understimate the time savings of
> MS Access queries, textbox controls that have pre-aligned labels, subforms, and
> the MS Access report writer. I've heard estimates from other people that the
> factor is as high as five.
>
> One guy I know (who is has more IQ points that me and my entire family put
> together) opined that he could do an app in VB about as fast as in Access - but
> he'd never actually done it.... so I'm sticking with the factor of three for MS
> Access vs VB6....
>
> Excluding the aforementioned possibilities of .NET, that makes MS Access the
> only game in town for me - bound or unbound....
> -----------------------
> PeteCresswell
Steve
Fenton) wrote:
>st...@nospam.com (Steve) wrote in
><3ed39c54....@news.westnet.com>:
>
>>Thats exactly what I said several posts before, but such comment
>>was met with criticism. Maybe some people like to argue just for
>>the sake of it.
>
>I didn't get that from what you wrote at all. I got a blanket
>condemnation of unbound forms.
>
>--
What I clearly wrote is that unbound forms improve performance (which
you disagreed with -- you stated that it "impacted" performance), and
I stated that
"Anyone who feels that their system requires unbound forms for
data entry, need to consider if Access is the most appropriate
tool."
David, where is the blanket condemnation? Please show any one of my
posts that does so! We are basically saying the same thing but you
just feel the need disagree for the sake of it.
Steven
David W. Fenton
<3ed3f469....@news.westnet.com>:
No, your statement is *very* different.
I said if you're doing *most* of your data editing unbound, you
said the mere possibility that you're thinking of requiring an
unbound form means you may be using the wrong tool.
I think those two statements are extremely different.
There are plenty of good reasons for using an unbound form for data
editing in Access in the appropriate circumstances. The fact of
doing so does not in any way indicate anything about whether or not
you've chosen the wrong tool.
On the other hand, if you seem to think that *all* your data
editing forms need to be unbound, then either the tool is wrong or
the developer is not making the right judgments about what is and
is not necessary for the application.
David W. Fenton
<2hv7dv4fhqitut94v...@4ax.com>:
>RE/
>> Citrix has tried to reduce the lag by moving the application to
>>servers with lower loads but the performance is still what I
>>would call unacceptable. I still regret designing the
>>application all in Access for the Metaframe. I told them that
>>the next application I do for them would use a web interface.
>>Also, after that experience, I question whether I would ever
>>recommend using Citrix Metaframe for any new applications when
>>creating a web interface is an option.
>
>Thanks...you may have saved my client a bunch of manhours and me
>from having egg on my face... It's ASP or Windows.NET for sure
>for this thing then...
For what it's worth, the person you are responding to is the only
one I know of how has ever made a claim that Windows Terminal
Server has such problems. And, in fact, he said Citrix, not WTS, so
it's not even clear if he's working with Win2K or with NT 4 + the
Citrix Metaframe extensions. Most of the features that made
purchase of the Citrix Metaframe add-ons to NT 4 so necessary were
incorporated by MS into the Win2K version of WTS.
So, I wouldn't be so quick to dismiss WTS until I had more
information about exactly what the circumstances were.
And maybe the Metaframe extensions don't work as well in Win2K as
they did in NT 4.
>I don't know diddley about ASP.NET or HTML, but it seems to me
>like this particular screen (a time entry screen) should be
>straightforward enough for me to farm it out to somebody in the
>client's department who has that kind of experience.
I don't see any reason why, if the WTS infrastructure is not
already in place, you cannot test it and see how it works.
>Biggest source of complexity is the pivot-style
>presentation...i.e. taking a table whose rows are hours worked and
>date and flipping it into one row per project/week. But that's
>already being done by stored procedures and all the HTML page has
>to do is feed the server a pay week, present the results, let the
>user edit same, and blow it all back to the server.
Well, do whatever you want, but I would not take the rather
nebulous word of one single poster (who is claiming authority that
he can't really prove) on this. I'd test it for myself and find out
what the issues are, especially given how happy most of us are with
using WTS with our Access apps.
David W. Fenton
<3ed4d998...@news.westnet.com>:
>On Tue, 27 May 2003 21:33:43 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
>>st...@nospam.com (Steve) wrote in
>><3ed39c54....@news.westnet.com>:
>>
>>>Thats exactly what I said several posts before, but such comment
>>>was met with criticism. Maybe some people like to argue just
>>>for the sake of it.
>>
>>I didn't get that from what you wrote at all. I got a blanket
>>condemnation of unbound forms.
>
>What I clearly wrote is that unbound forms improve performance
>(which you disagreed with -- you stated that it "impacted"
>performance), and I stated that
>
>"Anyone who feels that their system requires unbound forms for
>data entry, need to consider if Access is the most appropriate
>tool."
>
>David, where is the blanket condemnation? Please show any one of
>my posts that does so! We are basically saying the same thing but
>you just feel the need disagree for the sake of it.
Well, it's clear that you view this as a glass-half-full vs.
glass-half-empty situation.
But your formula sounds to me like it's saying any time you venture
into even *one* unbound form for data entry, you're reaching the
point where you may be using the wrong tool.
I'm saying that you only reach that point if you're choosing to do
nearly *all* your data entry with unbound forms. We are on the same
continuum, but at opposite ends.
Maybe you were saying the same thing, but I just didn't read it
that way at all.
Obviously, we could all write more clearly sometimes and avoid
these unnecessary little near disagreements.
Of course, I've always said it's much more fun to argue when you're
in 99% agreement! When people *really* disagree, it gets unpleasant
really fast!
Steve
Fenton) wrote:
>st...@nospam.com (Steve) wrote in
>>"Anyone who feels that their system requires unbound forms for
>>data entry, need to consider if Access is the most appropriate
>>tool."
>>
>
>No, your statement is *very* different.
>
>I said if you're doing *most* of your data editing unbound, you
>said the mere possibility that you're thinking of requiring an
>unbound form means you may be using the wrong tool.
>
See previous reply.
Steven
<snip>
Steve
Fenton) wrote:
>st...@nospam.com (Steve) wrote in
><3ed4d998...@news.westnet.com>:
>
>>"Anyone who feels that their system requires unbound forms for
>>data entry, need to consider if Access is the most appropriate
>>tool."
>>
>Well, it's clear that you view this as a glass-half-full vs.
>glass-half-empty situation.
No, I view it as I stated it.
>
>But your formula sounds to me like it's saying any time you venture
>into even *one* unbound form for data entry, you're reaching the
>point where you may be using the wrong tool.
>
Your interpretation does not reflect the above wording. I use the
plural "unbound forms", which clearly rules out your interpretation of
*one*.
Actually, if you read the statement closely, one can interpret it as
using unbound forms for all data entry. I don't limit the use of
unbound forms above, I just say for "data entry". Since I don't
explicitly limit data entry, there is no reason to imply such
limitation.
Looking at it another way, if I said "I use bound forms for data
entry", one would imply that meant for all data entry.
>I'm saying that you only reach that point if you're choosing to do
>nearly *all* your data entry with unbound forms. We are on the same
>continuum, but at opposite ends.
>
I don't think so.
>Maybe you were saying the same thing, but I just didn't read it
>that way at all.
>
Ok.
>Obviously, we could all write more clearly sometimes and avoid
>these unnecessary little near disagreements.
>
That's why we have lawyers :(.
What "ticked" me off was when you, in a your prior 5/25 post, esponded
to my statement above by stating:
"Well, I don't make categorical statements about this. It depends on
the application and the requirements"
And then you continue with your statements.
>Of course, I've always said it's much more fun to argue when you're
>in 99% agreement! When people *really* disagree, it gets unpleasant
>really fast!
>
I prefer to debate to further enhance knowledge. When people "really"
disagree, more knowledge can be obtained by both parties. It really
does not have to get nasty.
It get's nasty because people feel the need to "win", instead of
discovering additional information and view points.
Steven
David W. Fenton
<3ed56061...@news.westnet.com>:
>On Wed, 28 May 2003 20:14:06 GMT, dXXXf...@bway.net (David W.
>Fenton) wrote:
>
>>st...@nospam.com (Steve) wrote in
>><3ed4d998...@news.westnet.com>:
>>
>>>"Anyone who feels that their system requires unbound forms for
>>>data entry, need to consider if Access is the most appropriate
>>>tool."
>>>
>
>>Well, it's clear that you view this as a glass-half-full vs.
>>glass-half-empty situation.
>
>No, I view it as I stated it.
Well, I don't.
>>But your formula sounds to me like it's saying any time you
>>venture into even *one* unbound form for data entry, you're
>>reaching the point where you may be using the wrong tool.
>>
>
>Your interpretation does not reflect the above wording. I use the
>plural "unbound forms", which clearly rules out your
>interpretation of *one*.
OK, your rule kicks in at TWO forms.
As far as I'm concerned, that's about the same thing.
>Actually, if you read the statement closely, one can interpret it
>as using unbound forms for all data entry. I don't limit the use
>of unbound forms above, I just say for "data entry". Since I
>don't explicitly limit data entry, there is no reason to imply
>such limitation.
Well, perhaps. I didn't read it that way, since it wasn't clear to
me that you meant it to be read that way.
>Looking at it another way, if I said "I use bound forms for data
>entry", one would imply that meant for all data entry.
Look, I don't care to argue about it. I didn't get from what you
wrote the ideas that you intended to convey. I still don't.
We can agree that I missed your point.
Let's not bother to try to determine whose fault it was.
>>I'm saying that you only reach that point if you're choosing to
>>do nearly *all* your data entry with unbound forms. We are on the
>>same continuum, but at opposite ends.
>
>I don't think so.
Well, now that you've explained what you meant by your statement, I
guess not.
But, rightly or wrongly, I didn't understand that until you
explained what you meant.
[]
>>Obviously, we could all write more clearly sometimes and avoid
>>these unnecessary little near disagreements.
>>
>
>That's why we have lawyers :(.
>
>What "ticked" me off was when you, in a your prior 5/25 post,
>esponded to my statement above by stating:
>
>"Well, I don't make categorical statements about this. It depends
>on the application and the requirements"
>
>And then you continue with your statements.
>
>>Of course, I've always said it's much more fun to argue when
>>you're in 99% agreement! When people *really* disagree, it gets
>>unpleasant really fast!
>
>I prefer to debate to further enhance knowledge. When people
>"really" disagree, more knowledge can be obtained by both parties.
> It really does not have to get nasty.
>
>It get's nasty because people feel the need to "win", instead of
>discovering additional information and view points.
Well, to be frank, if you'd written what you meant on the first go,
we wouldn't be having this discussion.
I'm done.
Steven R. Zuch
> >plural "unbound forms", which clearly rules out your
> >interpretation of *one*.
>
> OK, your rule kicks in at TWO forms.
>
Plural just means two? Gee.
<snip>
> We can agree that I missed your point.
>
> Let's not bother to try to determine whose fault it was.
>
Ok
<snip>
> Well, to be frank, if you'd written what you meant on the first go,
> we wouldn't be having this discussion.
>
I though we weren't in the blame business?
> I'm done.
Peter Chong
Pete
I wrote a program to simulate the wizard in access for automatically
bound to data source, the ASP.NET is code base and much easier than
object data like access, it is standard ASCII text file format, and
few different type of forms
1. Pivot table, master-detail-subdetail, edit, dynamic query..
Check the download section of www.exmlsoft.com, just need access data
base point and click it will generates a code that you could modify
later....
Happy computing