Access 2007 Technical Questions

[Sam Hobbs]

I am getting in here without the benefit of the beginning. There is a lot to
read in this thread and I can't see all of it. So my comments might not be
relevant.

I get the impression however that this application is too complex for
Access. I see that others have also suggested that.

Some people might say that Access is better because it makes things easier.
User-friendly tools such as Access makes things easier if they were designed
to do what needs to be done. If the requirements of an application includes
things that a tool such as Access was not designed to do, then it is usually
more difficult to use the tool to satisfy those requirements.

I don't understand the problems you are having with validation and the other
UI problems, but I get the impression that they would be relatively easily
solved using VB. VB does not have the database processing features that
Access does but VB does have UI advantages that Access does not. I am not
sure but probably most of the database fetures that Access has are for
user-oriented conveniences that are essentially not relevant for most
applications.

Someone said that VB does not have bound forms, but I am more than 99% sure
it does. Even if it does not, or if they cannot be used for a specific
application, I think the amount of work to do the equivalent is small
compared to the work to do other UI things.

 

[Ronald Dodge]

I understand where you coming in with this thought process, which is
something that most definitely needs to be taken into account. If anything
would be too large/complex for this project to be in Access, it would be the
amount of data that's projected to be needed, which in that case would be
much better to go with SQL Server. However, at the company, I'm not at that
luxury.

Although I do have VB.Net Standard Edition, it would still require a lot of
extra work cause as many others has said, you don't get the bound
forms/controls that you have within Access. Although I wasn't using it
within Access, but ADO has the limitation that you can't use Dynamic Cursor
Keyset against a Jet Engine, which in return doesn't allow for the option to
see changes effectively speaking. On the other hand, DAO coding is done
within Access, which to my understanding isn't available to other programs
outside of Access, which is also the same set of coding that bound
forms/controls use, just done behind the scenes.

More or less the order of events that I would be having done is as follows:

Control A = A, the control/field being validated when user attempts to leave
that control
Control B = B, the control/field which the user is attempting to activate

A:BeforeUpdate Event (This event does the actual validation, but still need
to set a variable to indicate if it's valid or not along with other
possibilities, but yet, given the user friendliness issues, can't ever set
the Cancel variable within this event to "True", unless that is what you
want 100% of the time in 100% of the different situations.)
A:AfterUpdate Event
A:Exit Event (Given user friendliness issues, can't ever set the Cancel
variable within this event to "True", unless that is what you want 100% of
the time in 100% of the different situations.)
A:LostFocus Event
B:Enter Event (Set a variable to hold what control is attempting to get the
focus)
B: Check CausesValidation Property
If CausesValidation Property is True Then
A:Validation Event (This event determines what is allowed to have
the focus, should validation not be adequate [the control as not being valid
or the control the user attempts to activate])


Note, the above is for all field levels, which then if the focus wasn't sent
back to the control marked as invalid, and form level stuff is to take
place, this would be when it would take place.

 

[Sam Hobbs]

I said that VB does also have bound controls. You can even have bound
controls in ASP pages and I am nearly certain that you can have bound
controls in a HTML page.

DAO is definitely available outside of Access. DAO is known as the database
facility for VB. Microsoft definitely recommends to not use DAO; even the
Access documentation says that. A while back, Microsoft said that most of
the database software will not be available for future versions of Winows.
DAO will probably not be unavailable in the future. I think that what
Microsoft is saying is that you will be able to use the libraries for things
such as DAO if you have them when you upgrade to newer versions of Windows
but the libraries will not be provided by nor available from Microsoft for
newer versions of Windows.

You really should determine what Microsoft recommends for new development.

I realy think that VB will be less work overall for the reasons I already
explained.

I understand where you coming in with this thought process, which is
something that most definitely needs to be taken into account. If
anything
would be too large/complex for this project to be in Access, it would be
the
amount of data that's projected to be needed, which in that case would be
much better to go with SQL Server. However, at the company, I'm not at
that
luxury.

Although I do have VB.Net Standard Edition, it would still require a lot
of
extra work cause as many others has said, you don't get the bound
forms/controls that you have within Access. Although I wasn't using it
within Access, but ADO has the limitation that you can't use Dynamic
Cursor
Keyset against a Jet Engine, which in return doesn't allow for the option
to
see changes effectively speaking. On the other hand, DAO coding is done
within Access, which to my understanding isn't available to other programs
outside of Access, which is also the same set of coding that bound
forms/controls use, just done behind the scenes.

More or less the order of events that I would be having done is as
follows:

Control A = A, the control/field being validated when user attempts to
leave
that control
Control B = B, the control/field which the user is attempting to activate

A:BeforeUpdate Event (This event does the actual validation, but still
need
to set a variable to indicate if it's valid or not along with other
possibilities, but yet, given the user friendliness issues, can't ever set
the Cancel variable within this event to "True", unless that is what you
want 100% of the time in 100% of the different situations.)
A:AfterUpdate Event
A:Exit Event (Given user friendliness issues, can't ever set the Cancel
variable within this event to "True", unless that is what you want 100% of
the time in 100% of the different situations.)
A:LostFocus Event
B:Enter Event (Set a variable to hold what control is attempting to get
the
focus)
B: Check CausesValidation Property
If CausesValidation Property is True Then
A:Validation Event (This event determines what is allowed to have
the focus, should validation not be adequate [the control as not being
valid
or the control the user attempts to activate])


Note, the above is for all field levels, which then if the focus wasn't
sent
back to the control marked as invalid, and form level stuff is to take
place, this would be when it would take place.

--
Ronald R. Dodge, Jr.
Production Statistician/Programmer
Master MOUS 2000

I am getting in here without the benefit of the beginning. There is a lot to
read in this thread and I can't see all of it. So my comments might not
be
relevant.

I get the impression however that this application is too complex for
Access. I see that others have also suggested that.

Some people might say that Access is better because it makes things easier.
User-friendly tools such as Access makes things easier if they were designed
to do what needs to be done. If the requirements of an application includes
things that a tool such as Access was not designed to do, then it is usually
more difficult to use the tool to satisfy those requirements.

I don't understand the problems you are having with validation and the other
UI problems, but I get the impression that they would be relatively
easily
solved using VB. VB does not have the database processing features that
Access does but VB does have UI advantages that Access does not. I am not
sure but probably most of the database fetures that Access has are for
user-oriented conveniences that are essentially not relevant for most
applications.

Someone said that VB does not have bound forms, but I am more than 99% sure
it does. Even if it does not, or if they cannot be used for a specific
application, I think the amount of work to do the equivalent is small
compared to the work to do other UI things.

 

[Douglas J. Steele]

<picky>
VB doesn't have bound controls, although VB.Net does.

There are some ActiveX controls that you can use in VB that can be bound
(such as FlexGrid), but they're not really VB.
</picky>

--
Doug Steele, Microsoft Access MVP

(no private e-mails, please)

I said that VB does also have bound controls. You can even have bound
controls in ASP pages and I am nearly certain that you can have bound
controls in a HTML page.

DAO is definitely available outside of Access. DAO is known as the
database facility for VB. Microsoft definitely recommends to not use DAO;
even the Access documentation says that. A while back, Microsoft said that
most of the database software will not be available for future versions of
Winows. DAO will probably not be unavailable in the future. I think that
what Microsoft is saying is that you will be able to use the libraries for
things such as DAO if you have them when you upgrade to newer versions of
Windows but the libraries will not be provided by nor available from
Microsoft for newer versions of Windows.

You really should determine what Microsoft recommends for new development.

I realy think that VB will be less work overall for the reasons I already
explained.

I understand where you coming in with this thought process, which is
something that most definitely needs to be taken into account. If
anything
would be too large/complex for this project to be in Access, it would be
the
amount of data that's projected to be needed, which in that case would be
much better to go with SQL Server. However, at the company, I'm not at
that
luxury.

Although I do have VB.Net Standard Edition, it would still require a lot
of
extra work cause as many others has said, you don't get the bound
forms/controls that you have within Access. Although I wasn't using it
within Access, but ADO has the limitation that you can't use Dynamic
Cursor
Keyset against a Jet Engine, which in return doesn't allow for the option
to
see changes effectively speaking. On the other hand, DAO coding is done
within Access, which to my understanding isn't available to other
programs
outside of Access, which is also the same set of coding that bound
forms/controls use, just done behind the scenes.

More or less the order of events that I would be having done is as
follows:

Control A = A, the control/field being validated when user attempts to
leave
that control
Control B = B, the control/field which the user is attempting to activate

A:BeforeUpdate Event (This event does the actual validation, but still
need
to set a variable to indicate if it's valid or not along with other
possibilities, but yet, given the user friendliness issues, can't ever
set
the Cancel variable within this event to "True", unless that is what you
want 100% of the time in 100% of the different situations.)
A:AfterUpdate Event
A:Exit Event (Given user friendliness issues, can't ever set the Cancel
variable within this event to "True", unless that is what you want 100%
of
the time in 100% of the different situations.)
A:LostFocus Event
B:Enter Event (Set a variable to hold what control is attempting to get
the
focus)
B: Check CausesValidation Property
If CausesValidation Property is True Then
A:Validation Event (This event determines what is allowed to have
the focus, should validation not be adequate [the control as not being
valid
or the control the user attempts to activate])


Note, the above is for all field levels, which then if the focus wasn't
sent
back to the control marked as invalid, and form level stuff is to take
place, this would be when it would take place.

--
Ronald R. Dodge, Jr.
Production Statistician/Programmer
Master MOUS 2000

message

I am getting in here without the benefit of the beginning. There is a
lot to
read in this thread and I can't see all of it. So my comments might not
be
relevant.

I get the impression however that this application is too complex for
Access. I see that others have also suggested that.

Some people might say that Access is better because it makes things easier.
User-friendly tools such as Access makes things easier if they were designed
to do what needs to be done. If the requirements of an application includes
things that a tool such as Access was not designed to do, then it is usually
more difficult to use the tool to satisfy those requirements.

I don't understand the problems you are having with validation and the other
UI problems, but I get the impression that they would be relatively
easily
solved using VB. VB does not have the database processing features that
Access does but VB does have UI advantages that Access does not. I am
not
sure but probably most of the database fetures that Access has are for
user-oriented conveniences that are essentially not relevant for most
applications.

Someone said that VB does not have bound forms, but I am more than 99% sure
it does. Even if it does not, or if they cannot be used for a specific
application, I think the amount of work to do the equivalent is small
compared to the work to do other UI things.