Need advice on FE/BE development

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi Experts :)

if we create our DBs FE/BE using MsAccess, will it be the best option
between the only two available to our department, I mean, MsAccess Tool
and only programming???

Thanks
 
Not sure what you are asking ...
But the database should be split .. espcecially in a multi user environment.
Each user should have a seperate FE that is linked to a single BE file ...

R. Hicks
 
Pascale Breton said:
Hi Experts :)

if we create our DBs FE/BE using MsAccess, will it be the best option
between the only two available to our department, I mean, MsAccess Tool
and only programming???

I am not sure what you question is, but if you want to get a "grasp" as to
why you split, and what the advantages are, then you can read the following
article of mine.

Splitting a access database, or how to run ms-access in a multi-user mode
By Albert D. Kallal
http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm

The above is still draft...but it should help you understand the whole
process, and why it is good to split.
 
Pascale Breton said:
if we create our DBs FE/BE using MsAccess, will it be the best option
between the only two available to our department, I mean, MsAccess Tool
and only programming???

Could you explain your problem or objective with a bit more detail?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
OK for more details...

Well, in my department, there is actually 2 programmers. One is very
familiar with MsAccess, has develop a well-done functional application with
it. The second one pretend knowing everything but even if that using forms
and reports in MsAccess is an intermediate notion, she has never used those.
We are actually reviewing the databases she has created. Even the base, I
mean the tables and queries are a mess. So, she claimed that she and the
other programmer (without consulting this one) will create a FE/BE
application in MsAccess without using forms - probably because as you know,
she has never used it - but just by coding into MsAccess modules. The other
programmer do not think it is a good idea and so am I. What do you think
about that?


Thanks.
 
OK for more details...

Well, in my department, there is actually 2 programmers. One is very
familiar with MsAccess, has develop a well-done functional application with
it. The second one pretend knowing everything but even if that using forms
and reports in MsAccess is an intermediate notion, she has never used those.
We are actually reviewing the databases she has created. Even the base, I
mean the tables and queries are a mess. So, she claimed that she and the
other programmer (without consulting this one) will create a FE/BE
application in MsAccess without using forms - probably because as you know,
she has never used it - but just by coding into MsAccess modules. The other
programmer do not think it is a good idea and so am I. What do you think
about that?
 
OK for more details...

Well, in my department, there is actually 2 programmers. One is very
familiar with MsAccess, has develop a well-done functional application with
it. The second one pretend knowing everything but even if that using forms
and reports in MsAccess is an intermediate notion, she has never used those.
We are actually reviewing the databases she has created. Even the base, I
mean the tables and queries are a mess. So, she claimed that she and the
other programmer (without consulting this one) will create a FE/BE
application in MsAccess without using forms - probably because as you know,
she has never used it - but just by coding into MsAccess modules. The other
programmer do not think it is a good idea and so am I. What do you think
about that?
 
So, she claimed that she and the
other programmer (without consulting this one) will create a FE/BE
application in MsAccess without using forms - probably because as you
know,
she has never used it - but just by coding into MsAccess modules.

The above is not possible. Without forms, you don't have a application, and
cannot interact with the user in any way that is useful. How can you build a
ms-access application by "just coding into MsAccess modules". This is
complete nonsense.

So, the above does NOT MAKE any sense at all. You can't make a ms-access
application "just" by coding into ms-access modules. Ask your self of what
use is a application with no forms, or no interface that a user can work
with?

It is possible that the developer is talking about using a COMPLETE
DIFFERENT development tool like Visual Basic, or vb.net, and wiring the code
and building the forms in that system. In that case, you can use a mdb file
for the data store, but NOT use ms-access to create the application part, or
build the forms. So, this kind of suggestion and approach is quite common,
and is a reasonable approach. However, either way, you go to use SOMETHING
to build the forms and interface with. Perhaps the person is talking about
using a different system to build the interface/application part. (so, you
CAN just use ms-access to store the data only part (that so called split
part of the back end).

So, does the idea make sense? No, it sounds complete stupid.

either:

a) you are complete miss-understanding what that person is
suggesting.
(the suggestion to use another system to build forms etc. makes
sense)
(the suggestion to use only ms-access code and modules makes NO
sense).

b) that person is a compete idiot

So, based on the information so far, if you are miss-understanding the
person, then you are a fool. If you do understand that person, and they are
suggesting that no forms, or application development tools will be used,
then they are fools....

So, once you clarify what they mean here, one of you is going to look very
stupid (and, at this point, I don't know which one of you!).
 
Back
Top