Splitting db in front end and back end 
Author Message
 Splitting db in front end and back end

Hi,

Two very simple questions about splitting a db in a front-end and a
back-end .mdb
I am aware of the advantages because of the maintainability of the
application,but

1. What's the advantage of doing this apart from this reason?
2. How does it affect performance when I both place front and back-end
on a network drive?
   I then don't have to distribute all of the front-ends to the
"front-enders".

Thanks,

Gert



Sat, 23 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
Actually I have some advice on this matter for you.  To begin with,
when you split the database to have the tables in another database, it
is a good idea to create a dummy table on the split portion, and have a
dummy form on the front end, so that when the users open the front end
database, have the dummy form open and hidden in the background, that
will keep access from accessing and closing the back end every time it
references the tables.  (It will also help you work on the front end,
because it gets REAL slow if that dummy form isn't open.  Access has to
create a ldb file every time it accesses the backend database).
Secondly, the way that I have my database set up, I have the front end
on the local drives.  To do this, I am gonna create an installation
database that will install the front end database and all of it's
associated frills files on the local drive.  Then I have an update
function that has the local front end database look to see if it is the
current version, if it isn't it, runs an update database that updates
the local drive front end database with the newer version, from the
network drive.  That way the tables are the only functioning portion on
the network, and all of your front end functions run faster, since they
are on the local drive.  Just a suggestion!

Crying Wolf


Quote:
> Hi,

> Two very simple questions about splitting a db in a front-end and a
> back-end .mdb
> I am aware of the advantages because of the maintainability of the
> application,but

> 1. What's the advantage of doing this apart from this reason?
> 2. How does it affect performance when I both place front and back-end
> on a network drive?
>    I then don't have to distribute all of the front-ends to the
> "front-enders".

> Thanks,

> Gert

--
He who learns but does not think is lost, he who thinks but does not lea

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sat, 23 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
I'd love to hear more about your install database and how you work your
update feature!!! I've been trying to do this with a replica (WHAT A
MESS!!!) so any other options would be appreciated!!

Thanks in Advance

KatK



Quote:
> Actually I have some advice on this matter for you.  To begin with,
> when you split the database to have the tables in another database, it
> is a good idea to create a dummy table on the split portion, and have
a
> dummy form on the front end, so that when the users open the front end
> database, have the dummy form open and hidden in the background, that
> will keep access from accessing and closing the back end every time it
> references the tables.  (It will also help you work on the front end,
> because it gets REAL slow if that dummy form isn't open.  Access has
to
> create a ldb file every time it accesses the backend database).
> Secondly, the way that I have my database set up, I have the front end
> on the local drives.  To do this, I am gonna create an installation
> database that will install the front end database and all of it's
> associated frills files on the local drive.  Then I have an update
> function that has the local front end database look to see if it is
the
> current version, if it isn't it, runs an update database that updates
> the local drive front end database with the newer version, from the
> network drive.  That way the tables are the only functioning portion
on
> the network, and all of your front end functions run faster, since
they
> are on the local drive.  Just a suggestion!

> Crying Wolf


> > Hi,

> > Two very simple questions about splitting a db in a front-end and a
> > back-end .mdb
> > I am aware of the advantages because of the maintainability of the
> > application,but

> > 1. What's the advantage of doing this apart from this reason?
> > 2. How does it affect performance when I both place front and back-
end
> > on a network drive?
> >    I then don't have to distribute all of the front-ends to the
> > "front-enders".

> > Thanks,

> > Gert

> --
> He who learns but does not think is lost, he who thinks but does not
lea

> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
To tell you the truth, I haven't started the install and update portion
yet.  All the pieces are in place, with the exception of the utility
databases.  See, my back end database, has a table with a list of all of
the database versions.  Then, my front end database has a table with
just one entry in it, that one entry is that databases 'version'.  When
the database starts up, I use the Dlookup command with that version on
the table on the back end database.  If it returns Current, then the
start up process continues, if it doesn't, it is going to open a new
database, whose entire purpose in life is to ensure the front end
database is closed, then it is going to use a batch file to kill the
older version, and copy the new version from the network drive onto the
local drive.  Whalla, a new version is installed, then the utility
database will close itself, and reopen the database.  As far as the
installation, that is going to do basically the same thing.  See, at
this moment in time, there is an older version of the database on our
network drive.  Hopefully on Tuesday I will be presenting the 'v.1.0'
Database.  The back end is already on the network drive, however I want
each user to have the front end on their local drive.  To do that, I
will create a simple database that does nothing but copy all of the
related files, including the database, to the local drive, then it will
close itself and start the database front end.  Pretty simple.  If you
want exact code, Remind me here on Tuesday, or email me at

it!  Another trick is that my database uses icons, avi's and wav's,
which don't need to be bogging down the network drive.  So to ensure
that those files remain on the local drive, the database does a quick
test to see if those files exist, by comparing the list of files in a
front end table, to the actual drive (I have a module that determines if
a file or folder exists).  If the files or folders are missing, that
startup process creates a batch file that copies all of the missing
files, and creates all of the necessary folders. (in reverse order of
course) and it only copies those that are actually missing.  Anyways, if
you want any more detail, give a holler!

Crying Wolf



Quote:
> I'd love to hear more about your install database and how you work
your
> update feature!!! I've been trying to do this with a replica (WHAT A
> MESS!!!) so any other options would be appreciated!!

> Thanks in Advance

> KatK



> > Actually I have some advice on this matter for you.  To begin with,
> > when you split the database to have the tables in another database,
it
> > is a good idea to create a dummy table on the split portion, and
have
> a
> > dummy form on the front end, so that when the users open the front
end
> > database, have the dummy form open and hidden in the background,
that
> > will keep access from accessing and closing the back end every time
it
> > references the tables.  (It will also help you work on the front
end,
> > because it gets REAL slow if that dummy form isn't open.  Access has
> to
> > create a ldb file every time it accesses the backend database).
> > Secondly, the way that I have my database set up, I have the front
end
> > on the local drives.  To do this, I am gonna create an installation
> > database that will install the front end database and all of it's
> > associated frills files on the local drive.  Then I have an update
> > function that has the local front end database look to see if it is
> the
> > current version, if it isn't it, runs an update database that
updates
> > the local drive front end database with the newer version, from the
> > network drive.  That way the tables are the only functioning portion
> on
> > the network, and all of your front end functions run faster, since
> they
> > are on the local drive.  Just a suggestion!

> > Crying Wolf


> > > Hi,

> > > Two very simple questions about splitting a db in a front-end and
a
> > > back-end .mdb
> > > I am aware of the advantages because of the maintainability of the
> > > application,but

> > > 1. What's the advantage of doing this apart from this reason?
> > > 2. How does it affect performance when I both place front and
back-
> end
> > > on a network drive?
> > >    I then don't have to distribute all of the front-ends to the
> > > "front-enders".

> > > Thanks,

> > > Gert

> > --
> > He who learns but does not think is lost, he who thinks but does not
> lea

> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.

> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

--
He who learns but does not think is lost, he who thinks but does not lea

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
Currious to know what you mean by dummy table?


Quote:
> Actually I have some advice on this matter for you.  To begin with,
> when you split the database to have the tables in another database, it
> is a good idea to create a dummy table on the split portion, and have a
> dummy form on the front end, so that when the users open the front end
> database, have the dummy form open and hidden in the background, that
> will keep access from accessing and closing the back end every time it
> references the tables.  (It will also help you work on the front end,
> because it gets REAL slow if that dummy form isn't open.  Access has to
> create a ldb file every time it accesses the backend database).
> Secondly, the way that I have my database set up, I have the front end
> on the local drives.  To do this, I am gonna create an installation
> database that will install the front end database and all of it's
> associated frills files on the local drive.  Then I have an update
> function that has the local front end database look to see if it is the
> current version, if it isn't it, runs an update database that updates
> the local drive front end database with the newer version, from the
> network drive.  That way the tables are the only functioning portion on
> the network, and all of your front end functions run faster, since they
> are on the local drive.  Just a suggestion!

> Crying Wolf


> > Hi,

> > Two very simple questions about splitting a db in a front-end and a
> > back-end .mdb
> > I am aware of the advantages because of the maintainability of the
> > application,but

> > 1. What's the advantage of doing this apart from this reason?
> > 2. How does it affect performance when I both place front and back-end
> > on a network drive?
> >    I then don't have to distribute all of the front-ends to the
> > "front-enders".

> > Thanks,

> > Gert

> --
> He who learns but does not think is lost, he who thinks but does not lea

> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.



Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
Your app will run quite a bit slower over the network.  Remember, JET is on
the local client machine and thus having Front and back on the network would
require both dbs to cross the network.   You are also competing with the
network and all the other things going on over it.

When I update my frnts right now, I send a WINZIP file in Extractor(exe)
format.  The users click on it and it install to the drive I set as default.
Quick and easy, but not as efficient as Crying Wolfs.


Quote:
> Hi,

> Two very simple questions about splitting a db in a front-end and a
> back-end .mdb
> I am aware of the advantages because of the maintainability of the
> application,but

> 1. What's the advantage of doing this apart from this reason?
> 2. How does it affect performance when I both place front and back-end
> on a network drive?
>    I then don't have to distribute all of the front-ends to the
> "front-enders".

> Thanks,

> Gert



Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
Well, what I mean is a table that you can name anything, and put at
least one field on it, who cares what that field is, or what it's
named, as long as that table is on the backend database.  Then on your
front end database, create a Form from that table.  Then, when your
database starts up (the front end), if you have the start up process
open that form (hidden, or not) and keep that form open, until your
front end is closed, it will keep a 'link' open between the front end
and back end.  A passive link, so it's not really using network time,
but it prevents Access from creating and closing the ldb file on the
back end database!

Crying Wolf


Quote:
> Currious to know what you mean by dummy table?



> > Actually I have some advice on this matter for you.  To begin with,
> > when you split the database to have the tables in another database,
it
> > is a good idea to create a dummy table on the split portion, and
have a
> > dummy form on the front end, so that when the users open the front
end
> > database, have the dummy form open and hidden in the background,
that
> > will keep access from accessing and closing the back end every time
it
> > references the tables.  (It will also help you work on the front
end,
> > because it gets REAL slow if that dummy form isn't open.  Access
has to
> > create a ldb file every time it accesses the backend database).
> > Secondly, the way that I have my database set up, I have the front
end
> > on the local drives.  To do this, I am gonna create an installation
> > database that will install the front end database and all of it's
> > associated frills files on the local drive.  Then I have an update
> > function that has the local front end database look to see if it is
the
> > current version, if it isn't it, runs an update database that
updates
> > the local drive front end database with the newer version, from the
> > network drive.  That way the tables are the only functioning
portion on
> > the network, and all of your front end functions run faster, since
they
> > are on the local drive.  Just a suggestion!

> > Crying Wolf


> > > Hi,

> > > Two very simple questions about splitting a db in a front-end and
a
> > > back-end .mdb
> > > I am aware of the advantages because of the maintainability of the
> > > application,but

> > > 1. What's the advantage of doing this apart from this reason?
> > > 2. How does it affect performance when I both place front and
back-end
> > > on a network drive?
> > >    I then don't have to distribute all of the front-ends to the
> > > "front-enders".

> > > Thanks,

> > > Gert

> > --
> > He who learns but does not think is lost, he who thinks but does
not lea

> > Sent via Deja.com http://www.deja.com/
> > Share what you know. Learn what you don't.

--
He who learns but does not think is lost, he who thinks but does not lea

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
Well I was sorta blessed and cursed with my database project.  I have
lots of computer experience, but before I started making this database,
I had never seen Access.  However, I am also a mechanic, and this
database is for mechanics, in fact, only two or three people that are
going to use my database are even close to being computer literate.  So
I had to make my database as user friendly as possible.  It is hard
enough to get them to double click the database icon, and enter their
password, if they had to do anything to update the front end I would
get a migrane from all the whining! hehehehe.  Necessity is the mother
of invention right? hehehe

Crying Wolf


Quote:
> Your app will run quite a bit slower over the network.  Remember, JET
is on
> the local client machine and thus having Front and back on the
network would
> require both dbs to cross the network.   You are also competing with
the
> network and all the other things going on over it.

> When I update my frnts right now, I send a WINZIP file in Extractor
(exe)
> format.  The users click on it and it install to the drive I set as
default.
> Quick and easy, but not as efficient as Crying Wolfs.



> > Hi,

> > Two very simple questions about splitting a db in a front-end and a
> > back-end .mdb
> > I am aware of the advantages because of the maintainability of the
> > application,but

> > 1. What's the advantage of doing this apart from this reason?
> > 2. How does it affect performance when I both place front and back-
end
> > on a network drive?
> >    I then don't have to distribute all of the front-ends to the
> > "front-enders".

> > Thanks,

> > Gert

--
He who learns but does not think is lost, he who thinks but does not lea

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
If there are so many users that an .ldb is always open, it it still
necessary to use the dummy form/table??


Quote:
> Actually I have some advice on this matter for you.  To begin with,
> when you split the database to have the tables in another database, it
> is a good idea to create a dummy table on the split portion, and have a
> dummy form on the front end, so that when the users open the front end
> database, have the dummy form open and hidden in the background, that
> will keep access from accessing and closing the back end every time it
> references the tables.  (It will also help you work on the front end,
> because it gets REAL slow if that dummy form isn't open.  Access has to
> create a ldb file every time it accesses the backend database).

t you don't.


Sun, 24 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
Yes, because even though the .ldb file may still remain open, if you
don't maintain a constant link between the front end and back end
databases, then Access still CHANGES the .ldb file.  The .ldb file
actually is a good way to track users online in a multi user
environment.  But to answer your question, yes, the dummy table and
form would still be needed (but not necessisary(sp?).

Crying Wolf


Quote:
> If there are so many users that an .ldb is always open, it it still
> necessary to use the dummy form/table??



> > Actually I have some advice on this matter for you.  To begin with,
> > when you split the database to have the tables in another database,
it
> > is a good idea to create a dummy table on the split portion, and
have a
> > dummy form on the front end, so that when the users open the front
end
> > database, have the dummy form open and hidden in the background,
that
> > will keep access from accessing and closing the back end every time
it
> > references the tables.  (It will also help you work on the front
end,
> > because it gets REAL slow if that dummy form isn't open.  Access
has to
> > create a ldb file every time it accesses the backend database).
> t you don't.

--
He who learns but does not think is lost, he who thinks but does not lea

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.



Mon, 25 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end

Quote:

>Actually I have some advice on this matter for you.  To begin with,
>when you split the database to have the tables in another database, it
>is a good idea to create a dummy table on the split portion, and have a
>dummy form on the front end, so that when the users open the front end
>database, have the dummy form open and hidden in the background, that
>will keep access from accessing and closing the back end every time it
>references the tables. '

I always have a GlobalOptions table with such items as CompanyName,
TaxPercentage and such.  I have a hidden GlobalOptions form with this
data on it which I am continually referencing in various places
throughout the database.

Tony
----
Message posted to newsgroup and, if appropriate, emailed.
Tony Toews, Independent Computer Consultant
Microsoft Access Links, Hints, Tips & Accounting Systems at
   http://www.granite.ab.ca/accsmstr.htm
VolStar http://www.volstar.com Manage hundreds or
   thousands of volunteers for special events.



Thu, 28 Feb 2002 03:00:00 GMT  
 Splitting db in front end and back end
I would like to see how you've done the install and the upgrade
databases if you don't mind. It would really help me out. I have
completely given up on replication - just made my database grow x3!
Thanks in advance for the help!!

KatK



Quote:
> Anyways, if
> you want any more detail, give a holler!

> Crying Wolf

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


Sat, 02 Mar 2002 03:00:00 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. VB Front end dll loses connection to back end SQL server db after an hour

2. A2k: Controlling a back-end MDB from its FRONT-end MDB

3. A2K Updating Back End with new fields from Front End

4. Compact the back-end data from the front-end

5. Corrupted back end corrputs all front ends!

6. Compact back-end front-end

7. Trying to Create a communicator for VB.net Front End and SQL 2000 back end

8. Front-End & Back-End

9. Packaging a VB front end/Access back end application

10. Access Back End, VB Front End -- Why?

11. Access Back End, VB Front End -- Why?

12. App Security - front-end or back-end?

 

 
Powered by phpBB® Forum Software