More then one person entering data on the same forum at the same t

[Guest]

I work at a computer helpdesk and we have to document all our calls, we have
a ticketing system that we use most of the time but every now and then it
goes down.

I am trying to create a backup system for when it goes down. The problem I
am runing in to is when when two people are on say record 1 the person that
saves first gets the information in there and the second person gets an error
saying the info in this form is newer then it was when you opened it, do you
want to save the current information, obviously if they say yes then the
first persons info is lost.

Is there a way to change access or my save button so that it will put the
info in the next empty record?

 

[Joseph Meehan]

I work at a computer helpdesk and we have to document all our calls,
we have a ticketing system that we use most of the time but every now
and then it goes down.

I am trying to create a backup system for when it goes down. The
problem I am runing in to is when when two people are on say record 1
the person that saves first gets the information in there and the
second person gets an error saying the info in this form is newer
then it was when you opened it, do you want to save the current
information, obviously if they say yes then the first persons info is
lost.

Is there a way to change access or my save button so that it will put
the info in the next empty record?

If you are adding records, not editing them, you can batch your records.
This of course assumes you are using a split database system with each user
having their own copy of the front end linked to the shared back end on the
LAN. You add new records to a temp table on your front end and at an agreed
upon time you run an append query linked to the back end table. The
disadvantage is that others can not see the records you entered until you do
the append.

Someone else may have a better solution for your situation, this one has
always worked for me.

BTW if you don't have a split database now, I strongly suggest you
create one as that may resolve most if not all of your problem.

 

[Nikos Yannacopoulos]

For what it's worth, I use unbound forms for data entry, and save
through a command button when all data is entered, so the whole record
is created in a flash, limiting the chance of a conflict to next to
nothing (and I've never had an issue to date).

Nikos

 

[Guest]

Everything I do in access I learned by just playing with it, I have made some
cool databases but I have never made one for actual use, so this is the first
time I have had to deal with this sort of situation.

Joseph, would you mind posting a little more on split databases and how they
are created?

Nikos, to enter info on to a form you must have text boxes each of these
text boxes has to be assigned to a field in the database(tell me if im
wrong). From what I can tell you are suggesting that all the info be entered
in these alt fields and then your command button tranfers all the data to the
actuall database.

How do I configure a command button to do this?
Am I even close on my guess as to how this is done?

Thanx for the replays.

 

[Joseph Meehan]

Everything I do in access I learned by just playing with it, I have
made some cool databases but I have never made one for actual use, so
this is the first time I have had to deal with this sort of situation.

Joseph, would you mind posting a little more on split databases and
how they are created?

Take a look under the Tools menu then database utilities. You will find
a wizard to help you actually do it. The help file should also include
information on split databases. In general you want to keep only the
dynamic data in the back end (that is data that is changed) and everything
else (including static data - data that does not change like look up files)
in the front end.

 

[Tony Toews]

Joseph, would you mind posting a little more on split databases and how they
are created?

You want to split the MDB into a front end containing the queries,
forms, reports, macros and modules with just the tables and
relationships. The FE is copied to each network users computer. The
FE MDB is linked to the tables in the back end MDB which resides on a
server. You make updates to the FE MDB and distribute them to the
users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at http://www.granite.ab.ca/access/splitapp/ for more info. See the
Auto FE Updater downloads page
http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. It also supports Terminal Server/Citrix quite nicely.

Nikos, to enter info on to a form you must have text boxes each of these
text boxes has to be assigned to a field in the database(tell me if im
wrong). From what I can tell you are suggesting that all the info be entered
in these alt fields and then your command button tranfers all the data to the
actuall database.

How do I configure a command button to do this?
Am I even close on my guess as to how this is done?

This also requires a lot of VBA code..

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

 

[Nikos Yannacopoulos]

Nikos, to enter info on to a form you must have text boxes each of these
text boxes has to be assigned to a field in the database(tell me if im
wrong).

Strictly speaking, this is not accurate; to enter data in a form you
need to have the appropriate controls on it (text boxes, listboxes,
combo boxes, option groups etc.). Whether they are bound to table fields
or not, is immaterial at that stage. Forms don't store data on their
own, though; the reason why controls are usually bound to table fields
is so the data entered in them can be stored in the table(s).


From what I can tell you are suggesting that all the info be entered

in these alt fields and then your command button tranfers all the data to the
actuall database.

No "alt fields", just unbound controls. No need for a pair (unbound /
bound) of controls for each table field, as you seem to guess. The data
entered in the unbound controls is stored directly in the table(s)
fields programatically, as Tony already explained.


Regards,
Nikos