Front End vs Back End

"Joe Cilinceon" wrote in message
...


Thanks Rick, I was wondering since the #1 program in my field does just
that. However it isn't a network setup but on 1 computer system.

No, likely does not do the above. If you do have a split database, then how
does the front end use, or execute queries in the back end?
(answer: you can't link to those queries, and you can't "see" them in the
front end).

The only reason why I can think of some queries in the back end is that they
are there for maintenance type stuff, or are not actually used. They also
could possibly be used if/when the back end is opened via automaton, but I
doubt that.

It is also possible they are "copied" on occasion from the back end to the
front end.

If you on occasions open up the back end for types of maintains, then those
queries can be used.

However, how can you use queries in the back end when you launch the front
end? You have to explain this to me, or what you say don't make sense?

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada

http://www.members.shaw.ca/AlbertKallal

"Albert D.Kallal" wrote in message


However, how can you use queries in the back end when you launch the
front end? You have to explain this to me, or what you say don't make
sense?

I suppose you could open a separate connection to the back-end (using
OpenDatabase in DAO, or via an ADO Connection object) and execute them
that way. But it's not clear to me what the point would be.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

People who don't have their application stored in
a database (like we do) still have to find somewhere
to store their queries.

They can store them as text in the executable.
They can store them as text resources in the executable.
They can store them in the same database where their data is stored.

Storing your queries in the same database where the
data is stored is often better than storing them
as text in the executable because

1) You can update the queries separately from the executable.
2) The queries hide the database internals from the executable.
3) The queries can be precompiled and optimised in the database.

You can partition your application into three (or more) layers:

Forms
Business Logic (queries)
Data

If you want to have a two layer system, you can make
a decision about where you want to place the middle
layer. You can even split the middle layer if you
want, with some queries in one place and some in
the other:

First the architecture implications:
VB6 + SQL Server = queries in database

Then the coding practice decisions:
VB6 + database = queries always in the same place for both MDB and SQL
Server

And the performance implications:
SQL Server = queries in BE database
Access MDB = queries in FE database

And the application development logic:
Frequent changes = stored with frequently changing stuff
Infrequent changes = stored with static stuff

So if your database structure was frequently
changing, you would naturally put queries there
so that your application didn't have to change
at all.

(david)

"JethroUK©" wrote in message
...
i've put a lot of work into my forms/reports and i want to protect &
seperate them from the main data tables

if i split the databse in two - should i leave the queries with the tables
or move the queries to the front end with the forms/reports (assuming i
have
a choice)

I was looking at the demo of the app again and to be honest I've never paid
any attention to the front end (exe file). I would assume that is it
probably written in some other such language and just uses the access file
structure for its tables. I never paid much attention to the front, as I
was more interested in their table design and relationships.


Albert D.Kallal wrote:
"Joe Cilinceon" wrote in message
...


No, likely does not do the above. If you do have a split database,
then how does the front end use, or execute queries in the back end?
(answer: you can't link to those queries, and you can't "see" them in
the front end).

The only reason why I can think of some queries in the back end is
that they are there for maintenance type stuff, or are not actually
used. They also could possibly be used if/when the back end is opened
via automaton, but I doubt that.

It is also possible they are "copied" on occasion from the back end
to the front end.

If you on occasions open up the back end for types of maintains, then
those queries can be used.

However, how can you use queries in the back end when you launch the
front end? You have to explain this to me, or what you say don't make
sense?

--

Joe Cilinceon

That's the point exactly, Joe. When the 'front-end' application is an Access
application, there's little if any reason to have queries in the 'back-end'
data MDB. But if the application is *not* an Access application, then there
are good reasons to save queries in an MDB.

--
Brendan Reynolds

"Joe Cilinceon" wrote in message
...
I was looking at the demo of the app again and to be honest I've never paid
any attention to the front end (exe file). I would assume that is it
probably written in some other such language and just uses the access file
structure for its tables. I never paid much attention to the front, as I
was more interested in their table design and relationships.


Albert D.Kallal wrote:
"Joe Cilinceon" wrote in message
...


No, likely does not do the above. If you do have a split database,
then how does the front end use, or execute queries in the back end?
(answer: you can't link to those queries, and you can't "see" them in
the front end).

The only reason why I can think of some queries in the back end is
that they are there for maintenance type stuff, or are not actually
used. They also could possibly be used if/when the back end is opened
via automaton, but I doubt that.

It is also possible they are "copied" on occasion from the back end
to the front end.

If you on occasions open up the back end for types of maintains, then
those queries can be used.

However, how can you use queries in the back end when you launch the
front end? You have to explain this to me, or what you say don't make
sense?

--

Joe Cilinceon

"Brendan Reynolds" wrote in message
...
That's the point exactly, Joe. When the 'front-end' application is an Access
application, there's little if any reason to have queries in the 'back-end'
data MDB. But if the application is *not* an Access application, then there
are good reasons to save queries in an MDB.

Yes the "point" changes entirely when the front end in not Access.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

Thanks Brenden & Rick for the explanations. I'm just trying to get a handle
on the why's of this.

--

Joe Cilinceon

Good post David. It provides a nice framework for thinking
about this issue.
--
Marsh
MVP [MS Access]


david epsom dot com dot au wrote:
People who don't have their application stored in
a database (like we do) still have to find somewhere
to store their queries.

They can store them as text in the executable.
They can store them as text resources in the executable.
They can store them in the same database where their data is stored.

Storing your queries in the same database where the
data is stored is often better than storing them
as text in the executable because

1) You can update the queries separately from the executable.
2) The queries hide the database internals from the executable.
3) The queries can be precompiled and optimised in the database.

You can partition your application into three (or more) layers:

Forms
Business Logic (queries)
Data

If you want to have a two layer system, you can make
a decision about where you want to place the middle
layer. You can even split the middle layer if you
want, with some queries in one place and some in
the other:

First the architecture implications:
VB6 + SQL Server = queries in database

Then the coding practice decisions:
VB6 + database = queries always in the same place for both MDB and SQL
Server

And the performance implications:
SQL Server = queries in BE database
Access MDB = queries in FE database

And the application development logic:
Frequent changes = stored with frequently changing stuff
Infrequent changes = stored with static stuff

So if your database structure was frequently
changing, you would naturally put queries there
so that your application didn't have to change
at all.


"JethroUK©" wrote
i've put a lot of work into my forms/reports and i want to protect &
seperate them from the main data tables

if i split the databse in two - should i leave the queries with the tables
or move the queries to the front end with the forms/reports (assuming i
have a choice)