Re: Advise
From: Larry Linson (bouncer_at_localhost.not)
Date: 02/21/04
- Next message: Stephen Lebans: "Re: bound object frame: picture"
- Previous message: Don Cardoza: "Re: FilterForm via VBA"
- In reply to: Michael Lam: "Re: Advise"
- Next in thread: Michael Lam: "Re: Advise"
- Reply: Michael Lam: "Re: Advise"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 20 Feb 2004 22:25:05 -0600
The purpose of AutoNumbers is to ensure uniqueness -- they are for use
internal to your database, for joining related tables and the like. They are
not for display to a user as "meaningful data". Even if you think that the
users will not be disturbed by a break in a
normally-monotonically-ascending-sequence, it is likely that they will...
and contact you or the Help Desk, asking "what happened to the missing IDs?"
You can "fetch" the next number from a shared table, from within a
transaction in which you also update it, I'd think. I've never tried a split
Access database over anything as slow as T-1 -- when our users were on a
WAN, we used a true client-server configuration. Split Access-Jet pumps a
lot of data over the network to be used on anything as slow as a shared 1.5
MB pipe. The slowest network I've used with split Access-Jet was an old 4
MBPS LAN, and you could certainly tell the difference between that and the
10 MBPS and 100 MBPs networks in the same office.
After you implement and test, you may decide that an Access client
application running against SQL Server (the free MSDE that comes with Access
is fine if you don't have too many users... it is deliberately slowed when
more than 5 concurrent internal "batch processes" run, but usually can
handle user audiences in the twenties without undue delays). You'll have to
do some more learning... just as a well-designed, well-implemented
single-user standalone database isn't necessarily and automatically a
well-designed, well-implemented multiuser database, it is also true that a
well-designed, well-implemented multiuser database isn't necessarily and
automatically a well-designed, well-implemented client-server database,
either. Both are likely to require some replanning, redesign, and revision.
Larry Linson
Microsoft Access MVP
"Michael Lam" <kl_mis@pacific.net.hk> wrote in message
news:eCI1b439DHA.1948@TK2MSFTNGP12.phx.gbl...
> Dear Larry
>
> Is there any way to avoid such situation cos that access program will be
> accessed by totally three offices (one local and two connected by T1
line )
>
> THx
>
> Michael Lam
> "Larry Linson" <bouncer@localhost.not> ¦b¶l¥ó
> news:OW1t5529DHA.2368@TK2MSFTNGP11.phx.gbl ¤¤¼¶¼g...
>
> "Michael Lam" <kl_mis@pacific.net.hk> wrote in message
> news:OZqV%23G19DHA.2404@TK2MSFTNGP12.phx.gbl...
> > thx , I have use the Autonumber already
> >
> > But I when test the form , It generate the number as soon as I start
keyin
> > the info. Is there any way to make the autonumber field generate number
> > after click the Save button ?
>
> No. That is not the way AutoNumber works, unless you are using an unbound
> form and writing the information from code to a table that has an
Autonumber
> field. I do not, as a general rule, think it a good idea to use unbound
> forms for data, because you have to reimplement functionality that is
> included in (and massively tested) Access.
>
> Larry Linson
> Microsoft Access MVP
>
>
>
>
- Next message: Stephen Lebans: "Re: bound object frame: picture"
- Previous message: Don Cardoza: "Re: FilterForm via VBA"
- In reply to: Michael Lam: "Re: Advise"
- Next in thread: Michael Lam: "Re: Advise"
- Reply: Michael Lam: "Re: Advise"
- Messages sorted by: [ date ] [ thread ]