Hi
We need some advice: We are thinking of upgrading our Access database
from Access 2000 to Access 2004.
How stable is MS Office 2003? (particularly Access 2003).
We are just a small company and this is a big decision for us(!) It's
not just the money it's committing to an new version of Access!
We have been runnning MS Access 2000 (from MS Office 2000) for the last
4 years. We are thinking of upgrading to MS Office 2003 (or possibly
Office 2002 ??).
Is there much diffence between the three MS Access versions 2000, 2002,
2003 - and if so what?!
We now have a huge volume of data (c.80MB +160MB of data) on our
customer behaviour, customer transactions etc etc on MS Access 2000. We
use it to do mail shots and all sorts.
That said we arent very advanced programmers - very much self taught.
So we probably arent using the more advanced features of Access.
But we our business is UTTERLY dependant on Access!
We find Access 2000 somewhat slow and clunky. And it has a habit of
crashing now and again. Our PCs are all running WindowsXP but are also
rather old (about 3.5 years old)...
So it's probably time we upgraded the software be we remain nervous...
- How hard is it to install the upgrade to MS Office 2003?
- We have been offered a 10 user license, but it's an OEM upgrad
version. Is this likely to be a problem.
- Is 2003 Access better than 2000 in any *significant* ways?
(e.g. faster? better functionality? more reliable? less bloated?)
- Or would we be better off just using Access 2002 not 2003?!
* * * * *
Finally any top tips on a cheap, honest, reliable place to buy the
software from?
All advice gratefully received...
Ship
Shiperton Henethe
47  4474 
Can I have a copy of Access 2004?, only joking, no such thing. Access 2003
is the latest version. Well Office 2003 is the most stable version yet of
the whole office suite. A lot of people say that Access 2002 and Access 2003
are more stable than Access 2000. The size of the data you are talking about
is medium size well within was access can cope with, how many users are you
running?
Your Access 2000 databases will run unconverted within Access 2003, the
newer versions of office are much more feature rich than Access 2000. To run
Office (any version 2000,2002,2003) you should have a minimum 256MB ram on
your workstations it does make a difference. If it all fails you can install
Access 2000 with Office 2003 but you will loose out on some of the
integrated features.
If you have been offered an OEM licence for Office they are almost certainly
not legit, as OEM should be provided with NEW hardware, also OEM has no
upgrade path at all. If you are trying to reduce costs then think about
this, Buy one full copy of Office 2003 Pro, Buy all the other copies as
Office 2003 standard, buy the Access Developer Extensions, this allows you
to run the runtime version of Access on the other computers, you would not
be able to do any modifications of forms etc from the other computers but
you would be able to run the database and enter/update/delete records and
run forms etc.
Hope it helps.
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"ship" <sh*****@yahoo.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Hi
We need some advice: We are thinking of upgrading our Access database
from Access 2000 to Access 2004.
How stable is MS Office 2003? (particularly Access 2003).
We are just a small company and this is a big decision for us(!) It's
not just the money it's committing to an new version of Access!
We have been runnning MS Access 2000 (from MS Office 2000) for the last
4 years. We are thinking of upgrading to MS Office 2003 (or possibly
Office 2002 ??).
Is there much diffence between the three MS Access versions 2000, 2002,
2003 - and if so what?!
We now have a huge volume of data (c.80MB +160MB of data) on our
customer behaviour, customer transactions etc etc on MS Access 2000. We
use it to do mail shots and all sorts.
That said we arent very advanced programmers - very much self taught.
So we probably arent using the more advanced features of Access.
But we our business is UTTERLY dependant on Access!
We find Access 2000 somewhat slow and clunky. And it has a habit of
crashing now and again. Our PCs are all running WindowsXP but are also
rather old (about 3.5 years old)...
So it's probably time we upgraded the software be we remain nervous...
- How hard is it to install the upgrade to MS Office 2003?
- We have been offered a 10 user license, but it's an OEM upgrad
version. Is this likely to be a problem.
- Is 2003 Access better than 2000 in any *significant* ways?
(e.g. faster? better functionality? more reliable? less bloated?)
- Or would we be better off just using Access 2002 not 2003?!
* * * * *
Finally any top tips on a cheap, honest, reliable place to buy the
software from?
All advice gratefully received...
Ship
Shiperton Henethe
Hello
In answer to some of your questions
Is there much diffence between the three MS Access versions 2000, 2002,
2003 - and if so what?!
From what Ive see the differences are cosmetic. If you are not using all the
features of Access 2000 you are not likely to use those of the hight
versions
We now have a huge volume of data (c.80MB +160MB of data) on our
customer behaviour, customer transactions etc etc on MS Access 2000. We
use it to do mail shots and all sorts.
160mb is not a huge amount of data by todays standards. Infact it is tiny.
Access 2000 will have no problem with this.
We find Access 2000 somewhat slow and clunky. And it has a habit of
crashing now and again. Our PCs are all running WindowsXP but are also
rather old (about 3.5 years old)...
I think the clunkiness of your Access Applications may be more to do with
the the age of your computers. You dont say what processors they have or how
much memory etc. 3.5 yrs old is getting on a bit in computer time. Also you
say you are self taught and dont have much programming experience. I'm also
self taught and Im finding that much of my earlier code is inefficient.
Perhaps this may be a factor too.
So it's probably time we upgraded the software be we remain nervous...
- How hard is it to install the upgrade to MS Office 2003?
It installs very simply over any earlier version replacing all the old
fiiles with the new ones
- We have been offered a 10 user license, but it's an OEM upgrad
version. Is this likely to be a problem.
I personally don't like to use a middle man for software. They tend not to
be around when you need them. I don't think microsoft are going to disappear
of the face of the earth soon.
- Is 2003 Access better than 2000 in any *significant* ways?
(e.g. faster? better functionality? more reliable? less bloated?)
It may possibly be slower on your computers if Access 2k is. Afterall I dont
think microsoft simplifies its software as it develops new versions.
- Or would we be better off just using Access 2002 not 2003?!
* * * * *
Finally any top tips on a cheap, honest, reliable place to buy the
software from?
I purchase most of my hardware online but have not done so for software
although it is significantly cheaper, and would be the best option if buget
is a major factor. Use an established firm.
In summary
Check your hardware spec first. Maybe try your Applications on a borrowed
more upto date PC/Server to see if it is less clunky and crashes less.
See if there is anyway you can improve your code
If Access 2K does what you want it to do stick with it. I don't see the
point in upgrading unless you intend to use the features of the new version.
Microsoft's website can tell you what the new features are. I did'nt notice
anything ground breaking when I recently used it. But then again I didnt
give it a good run.
Ian
All advice gratefully received...
Ship
Shiperton Henethe
If you haven't already, read Alex's message. It's dead on target!
Only one (sniggly) point. Access 97 was (is) the most stable version.
Upgrading to Access 2003 will reduce how often you databases crash,
depending upon your _network_. It's usually the network more then
anything else that causes Access to crash. Assuming you're running
your databases over a network, that is! (D'oh!)
The upgrade is a snore for any network administrator, and only slightly
more exciting for a user. (Mostly due to excitment or fear then
anything else.) Once the upgrade is in place however, even the most
scared user wonders why they felt that way. (Cudos to the Access
Development Team for that!!!!!)
"ship" <sh*****@yahoo.com> wrote We need some advice: We are thinking
of upgrading our Access database
from Access 2000 to Access 2004.
You've had some good advice on whether or not to upgrade.
Access 2000, provided you have applied _all_ released Service Packs (3, if I
recall correctly) and other patches, has reached a state of reasonably good
stability.
I would NOT _suggest_ distributing your applications with the runtime
support -- there are enough unobvious restrictions (a common statement is,
"Whoever would have thought _that_ was a design view feature?") and, of
course, your users would not have Access to use for their own purposes. It
can be done successfully, but IMNSHO, should only be done by experienced and
skilled developers -- if the users don't have any other use for Access.
If your users have full Access now, you'd be well advised to search out the
..MDB and .MDE files, just for the record. Remote searches in many companies
turned up a very surprising number of Access databases created by individual
users, some temporary and transitory, but others with data that needed to be
captured as a corporate asset.
There were a few real changes between Access 2000 and 2002 (obviously
nothing you couldn't live without) but very, very little change between
Access 2002 and Access 2003. Still, the changes in both cases were so minor
that, by default, they create databases in Access 2000 file format, so that
any new features just don't work. It's an easy option to change them to
2002/2003 file format if you don't have any users still using the older
version.
One other consideration: Access 2000 is now "out of support" at Microsoft,
so tech support is not required to answer questions about it. In practice,
this is not quite as drastic a problem as it may sound -- to determine how
it will affect you, consider how many times you have had to make support
calls to Microsoft about Access 2000 in the last <whatever period you decide
is pertinent>.
The current version of Access, and thus the one that will continue to be
supported for the longest time, is Access 2003. Its Help assumes primary
Help is online, so you will want your users to have (preferrably high-speed)
Internet access when using it; Access 2002's Help assumes local help
information is primary. Otherwise, there is almost no difference.
Because it is not current, you may be able to get a better deal on Office XP
Pro if you search various sources, including the online auction sites -- if
you are willing to "trade" a shorter official support period for a better
price.
Larry Linson
Microsoft Access MVP
"ship" <sh*****@yahoo.com> wrote in
news:11**********************@g49g2000cwa.googlegr oups.com: We have been runnning MS Access 2000 (from MS Office 2000) for the
last 4 years. We are thinking of upgrading to MS Office 2003 (or
possibly Office 2002 ??).
What benefit are you expecting to get from updating your version of
Office?
I have plenty of clients running Office97.
I have other clients running Office 2K, 2K2 and 2K3, but using
Access97 with the other Office apps.
I also have clients using A2K and A2K3 (nobody using A2K2, though).
I don't really see much of a difference from an end user's point of
view.
And I haven't programmed in A2K3, so I don't know about the
programmer's point of view directly, but have heard that it's
better.
I would consider upgrading Access and leaving the rest of the Office
suite alone, unless there are features in the new versions of the
other apps that are important. Personally, I've seen very little in
the recent versions of Word or Excel that would justify spending 10
cents upgrading.
If you use Outlook (and you shouldn't), then the new version of that
is improved in terms of security.
But since Office97, there just hasn't been any innovation in the
Office suite as a whole that would justify the upgrade.
On the other hand, if you're getting it preloaded on new PCs, then,
by all means, get the latest version of Office. It's so unchanged
that I've got clients who switch back and forth among Office 97,
Office 2K and 2K3 without blinking an eyelash.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
A little more to add,
In nearly all the upgrades that I have done from Access 97 to 2000 (+) have
been sold on Access 97 being unstable e.g. databases crashing etc, the
interesting thing that keeps on coming out of these upgrades is there is
some form of data corruption, of course upgrading did not solve this problem
and the data had to be cleaned, so there is an argument that the upgrade did
not make things anymore stable. When I am asked to advise on what version, I
will always go for 2000 unless there is a compelling reason for going with
either of the other two versions, why would I choose 2000, well it's simple
I have had the pain with 2000, I understand all the bugs (all software has
bugs) that affect me, I know exactly how to structure and 100+ form project
running on 100+ desktops so why change is my view.
I think before upgrading look at your hardware of your PC's, memory is the
number 1 issue, processor number 2. The clunky feel to your database could
be how it is structured, in a multi-user environment, split the database
front-end/back end (I don't know if you already have).
You have no choice but to purchase Office 2003 (Legitimately), but MS has a
downgrade rule, allowing you to run a previous version, (how many versions
back I don't know). I will reinforce my point about OEM, don't buy it you
are not entitled to it (unless you upgrade your machines at the same time,
you need to check with MS on the OEM rules), it is as legitimate as stealing
a copy off the internet.
On the point of how easy is the upgrade, well I never upgrade, I like to
completely get rid of the previous versions first, there is a tool for doing
that job on the MS Office website. I never install off CDROM, copy the CDROM
to a share on the server and install from there a lot less trouble, the
workstation never has the horible message "Now insert your Office CD in the
drive".
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"ship" <sh*****@yahoo.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...
Hi
We need some advice: We are thinking of upgrading our Access database
from Access 2000 to Access 2004.
How stable is MS Office 2003? (particularly Access 2003).
We are just a small company and this is a big decision for us(!) It's
not just the money it's committing to an new version of Access!
We have been runnning MS Access 2000 (from MS Office 2000) for the last
4 years. We are thinking of upgrading to MS Office 2003 (or possibly
Office 2002 ??).
Is there much diffence between the three MS Access versions 2000, 2002,
2003 - and if so what?!
We now have a huge volume of data (c.80MB +160MB of data) on our
customer behaviour, customer transactions etc etc on MS Access 2000. We
use it to do mail shots and all sorts.
That said we arent very advanced programmers - very much self taught.
So we probably arent using the more advanced features of Access.
But we our business is UTTERLY dependant on Access!
We find Access 2000 somewhat slow and clunky. And it has a habit of
crashing now and again. Our PCs are all running WindowsXP but are also
rather old (about 3.5 years old)...
So it's probably time we upgraded the software be we remain nervous...
- How hard is it to install the upgrade to MS Office 2003?
- We have been offered a 10 user license, but it's an OEM upgrad
version. Is this likely to be a problem.
- Is 2003 Access better than 2000 in any *significant* ways?
(e.g. faster? better functionality? more reliable? less bloated?)
- Or would we be better off just using Access 2002 not 2003?!
* * * * *
Finally any top tips on a cheap, honest, reliable place to buy the
software from?
All advice gratefully received...
Ship
Shiperton Henethe
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#R**************@TK2MSFTNGP14.phx.gbl: In nearly all the upgrades that I have done from Access 97 to 2000
(+) have been sold on Access 97 being unstable e.g. databases
crashing etc, the interesting thing that keeps on coming out of
these upgrades is there is some form of data corruption, of course
upgrading did not solve this problem and the data had to be
cleaned, so there is an argument that the upgrade did not make
things anymore stable.
Who is advising an upgrade from Access97 to Access2K to increase
stability? Only someone who is incompetent and has never really used
both versions to any extent would be fool enough to think that A2K
was *more* stable than A97.
The other point: if the upgrade is in response to instability
issues, anything that's causing instability in A97 is going to cause
instability in A2K (or any later version of Access), and it will
probably be worse.
There are perfectly valid reasons for upgrading.
Stability is not one of them, ever.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Hi David,
I totally agree, that is the point I was trying to make, out there in the
field amongst the user base there is the perception that the latest version
is going to be faster/more reliable I know that is not true, in my personal
view what made Access 2000 a 'better' (for want of a better word) was
suddenly the integration into SQL seemed much deeper. I inherit most of my
work from other programmers who seem to have run out of steam, their excuse
for their inability to deliver a working system was to blame the version of
Access. The most important thing to a good running Access database power of
the computers that it runs on, and that they are reliable. The point I was
trying to make is proven by my never advising on Access 2002 or 2003 unless
there is a compelling reason. We all have those jobs where they are
compacting a repair a bit too often, e.g. one a day, last year I had one
such client 1.4GB data, 15 concurrent users, running Access 2000, all I did
in that situation (as they were an SBS client, fully entitled to SQL) was
upsize the back-end to SQL, no one has had to get involved in that system
since. Having used every version of Access my favourites being v2,v97,v2000
it is horses for courses.
So in complete agreement with you,
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86... "Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#R**************@TK2MSFTNGP14.phx.gbl:
In nearly all the upgrades that I have done from Access 97 to 2000
(+) have been sold on Access 97 being unstable e.g. databases
crashing etc, the interesting thing that keeps on coming out of
these upgrades is there is some form of data corruption, of course
upgrading did not solve this problem and the data had to be
cleaned, so there is an argument that the upgrade did not make
things anymore stable.
Who is advising an upgrade from Access97 to Access2K to increase
stability? Only someone who is incompetent and has never really used
both versions to any extent would be fool enough to think that A2K
was *more* stable than A97.
The other point: if the upgrade is in response to instability
issues, anything that's causing instability in A97 is going to cause
instability in A2K (or any later version of Access), and it will
probably be worse.
There are perfectly valid reasons for upgrading.
Stability is not one of them, ever.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote Having used every version of Access
my favourites being v2,v97,v2000
it is horses for courses.
Access 2000? It is tolerably stable if all three SPs and subsequent updates
have been applied; but for a long period, it was in a close race with Access
95 for "worst release ever". (A95 _might_ have been OK if they'd put out 3
Service Packs.)
It is hard for me to imagine it being in anyone's "favorites" list.
Larry Linson
Microsoft Access MVP
"Alex White MCDBA MCSE" wrote Having used every version of Access my
favourites being v2,v97,v2000
it is horses for courses.
See my comments re: v2000 in comp.databases.ms-access in this thread. My
posting host for USENET doesn't carry all the microsoft.public.newsgroups.
Hi Larry,
Read your comments, it is interesting the different views we all have,
The funny thing for me is this, I wrote an Access 2000 ADP project in 1999
and with permission from MS I was allowed to deploy this application before
the release of Office 2000, this application has run faultlessly since
deployment and none of the service packs were applied in response to
specific problems, more out of the client insisting that they have the
latest SP's something that I have no control over. I would go as far as to
say that in the 13 years I have been developing Access applications it could
be said that, the specific application has had more man hours of users
beating it in every direction given it is run by 150+ users 6 days a week
and the whole business relies up on it and I don't ever get phone calls to
support it, ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I am interested in what makes Access 2000 not a good product, I do agree
with Access 95 I had all sorts of problems with that.
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"Larry Linson" <bo*****@localhost.not> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "Alex White MCDBA MCSE" wrote
Having used every version of Access my
favourites being v2,v97,v2000
it is horses for courses.
See my comments re: v2000 in comp.databases.ms-access in this thread. My
posting host for USENET doesn't carry all the microsoft.public.newsgroups.
Per Alex White MCDBA MCSE: ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions - which I've seen
be a major problem if/when something in the LAN environment is not right.
--
PeteCresswell
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#g**************@TK2MSFTNGP12.phx.gbl: I am interested in what makes Access 2000 not a good product, I do
agree with Access 95 I had all sorts of problems with that.
I don't do ADPs, nor do I ever intend to, so I don't know anything
about them beyond what I've read.
But with MDBs and Jet data sources, A2K is completely unusable in
any release before SR1 (Larry says Office SP3, but I've found that's
not necessary, nor desirable for sites using Outlook who want to
avoid the Draconian Outlook "security" "fix"), and with any version
of Jet 4 before SP6. The latter is now less of an Access-specific
issue, since Jet 4 is now shipped with the OS (since Win2K), as it
is used for storing the Active Directory database. If you've
service-packed your OS, you've already probably gotten a decent
version of Jet 4.
The problems with pre-SR1 Access and Jet 4.0 before SP6 are severe
enough that I log the versions of MSACCESS.EXE and MSJET40.DLL for
each user logon to any of may applications where I don't have full
control over the configuration of the desktops. That way I can
inform the sysadmins when a machine has reverted to a bad version of
Access 2K.
The problems with Jet 4.0 before SP6 were quite severe, real
show-stoppers.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Hi David and Peter,
I'm glad I asked the question now, because in both instances I don't have
the problems that both of you have experienced, for one I believe that
Outlook is one of the worst programs that MS ever wrote, and I never have
anything to do with it in a programming sense I fully understand the issues
with SP3 in office as I support more than 4000+ desktops with varying
applications, got loads of workarounds. I have completely written my own
emailing functions that I have been using for years now due to my complete
lack of respect for Outlook for anything other than a simple email
front-end. The Jet engine is great and I have many programs out there in the
field that just run and run, where I feel it lacks is in high volume
data/users and in those situations it's a SQL back-end every time, but I
have been doing that with every version of Access, it's just with 2000 (or
better) SQL was better integrated. As I said in an earlier post it is
interesting the different views/experiences we all have personally I am not
happy with either of the newer versions of Access beyond 2000 and I struggle
to find compelling reasons to upgrade to either from Access 2000. I have a
working solution that does it for me every time, Windows2000
Server/Windows2003 Server WinXP SP2 clients, Office 2000 With SP3, Latest
MDAC's latest Critical Updates, and on bigger installations SQL 2000, I put
these jobs in a don't here about any problems with my work, if anything I
phone them every 5-6 months asking if it is all going well.
With respect our views differ, but that what these newsgroups are about, if
we all thought the same, then just one person could answer all the
questions.
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"(PeteCresswell)" <x@y.z.invalid> wrote in message
news:ff********************************@4ax.com... Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions - which
I've seen
be a major problem if/when something in the LAN environment is not right.
--
PeteCresswell
"(PeteCresswell)" <x@y.z.invalid> wrote in
news:ff********************************@4ax.com: Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions -
which I've seen be a major problem if/when something in the LAN
environment is not right.
But that happens very, very seldom. I've only seen actual corruption
to the point of data loss a couple of times in 10 years of Access
development (all Jet back ends). And that happened in only two
different kinds of cases:
1. the client was doing no maintenance on the db at all, and storing
it on a workstation running unstable software that was constantly
crashing. The most memorable of these was back in the days of
Win3.x, and the client was running WordPerfect 6.0 on the
workstation where the Access 2 data file was stored.
2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
who did lose 3 records to corruption, ones that couldn't be
recovered after a corrupted primary key index.
I also once corrupted a client's database by running a huge append
operation against the live data file, and then killing the Access
process. I intended to run it against test data, but made a mistake.
My second mistake was killing the process. The file had to be sent
to Peter Miller for recovery and all the data was recovered.
I currently have a client with an unreliable network who is getting
"disk or network error" messages frequently, and they have not as
yet experienced any corruption of their replicated Jet 3.5 back end.
So, I'd say that Jet is not all the prone to corruption at all.
Of course, I'm defining corruption to be restricted to
non-recoverable corruption, since the only reason server databases
don't lose data is because you can run the transaction logs to
rebuild a corrupted data store. That's not the same as never
corrupting the data store (which does, in fact, happen), so, since
you're giving the benefit of the doubt to the server back end, I'm
giving the same to Jet.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#1**************@TK2MSFTNGP09.phx.gbl: I'm glad I asked the question now, because in both instances I
don't have the problems that both of you have experienced, for one
I believe that Outlook is one of the worst programs that MS ever
wrote, . . .
As an Internet email client, yes, it's garbage. And given its
dependencies on IE, it's pretty insecure. But. . .
. . . and I never have anything to do with it in a programming
sense I fully understand the issues with SP3 in office as I
support more than 4000+ desktops with varying applications, got
loads of workarounds. . . .
Well, I'm not the sysadmin for all of my clients, so I don't get to
choose whether or not they use Outlook. Thus, I have to recommend
the least invasive procedures for getting Access to run safely. And
that means NO SERVICE PACK 3 for those who are using Outlook, unless
the client decides they want to apply it themselves.
If I were in control, they wouldn't be using Outlook at all!
. . . I have completely written my own emailing
functions that I have been using for years now due to my complete
lack of respect for Outlook for anything other than a simple email
front-end. . . .
It sucks as a standalone email client.
It is only a good program when used in conjunction with Exchange
Server, where you get lots of useful functionality that just isn't
there in the standalone configuration.
. . . The Jet engine is great and I have many programs out
there in the field that just run and run, where I feel it lacks is
in high volume data/users and in those situations it's a SQL
back-end every time, but I have been doing that with every version
of Access, it's just with 2000 (or better) SQL was better
integrated. . . .
This is of no use to developers like me who don't develop apps to
run against SQL Server. If you did more pure-Jet development, you'd
be just as wary of Access 2000.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
David,
Thank you for you comments, read both of your posts, the difference between
your thoughts and mine are not worlds apart, we both live in the real world
not the one that MS prescribes for us (I am an MCDBA,MCSE the company that I
own is a MS gold Partner so I don't take my relationship lightly with MS),
but I will stand up and be counted on a number of issues related to their
products. What I will say in their defence is this, they strive to make the
best software products in the world, and when they are clearly behind they
will try a partnership or buyout, I have no problem with that, they also DO
listen to what people want, sometimes that can take a couple of versions, I
am prepared to wait. I will stand here and say I totally believe that Access
is one of the best (if not the best) product(s) they have ever been involved
in. As a programmer in a number of different systems (only one not MS being
perl currently) I am in the business in providing solutions to my clients
that solution has to be based on a few points, functionality, reliability,
cost (some people think this is the most important point, they all learn the
hard way), speed of delivery.
What the point of my reply is this,
A good database design is everything, without it, walk away from the
project, stability is in the foundations not the front-end, Normalizing to
3NF seems to produce the best all round results (base on time/cost). I came
from the DBase III world, Clipper (Still got loads running in the field)
Access was a revolution to me. I will stand by my original statement about
Access 2000 as all of my clients (that I have provided Access 2000 solutions
too) are still with me and they don't think I have had them.
In my humble view the only database that don't suffer the corruptions (at
the level) of MDB's are network level DB's like SQL as they are far more
robust due to network level transactions. Nearly all the true file level
databases corruptions I have seen could be associated with poor networks etc
not specific versions of Access. This is not me saying the products are
without fault, it's understanding the faults.
Good to speak....
I will respect others views, I may not agree with them.
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86... "(PeteCresswell)" <x@y.z.invalid> wrote in
news:ff********************************@4ax.com:
Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions -
which I've seen be a major problem if/when something in the LAN
environment is not right.
But that happens very, very seldom. I've only seen actual corruption
to the point of data loss a couple of times in 10 years of Access
development (all Jet back ends). And that happened in only two
different kinds of cases:
1. the client was doing no maintenance on the db at all, and storing
it on a workstation running unstable software that was constantly
crashing. The most memorable of these was back in the days of
Win3.x, and the client was running WordPerfect 6.0 on the
workstation where the Access 2 data file was stored.
2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
who did lose 3 records to corruption, ones that couldn't be
recovered after a corrupted primary key index.
I also once corrupted a client's database by running a huge append
operation against the live data file, and then killing the Access
process. I intended to run it against test data, but made a mistake.
My second mistake was killing the process. The file had to be sent
to Peter Miller for recovery and all the data was recovered.
I currently have a client with an unreliable network who is getting
"disk or network error" messages frequently, and they have not as
yet experienced any corruption of their replicated Jet 3.5 back end.
So, I'd say that Jet is not all the prone to corruption at all.
Of course, I'm defining corruption to be restricted to
non-recoverable corruption, since the only reason server databases
don't lose data is because you can run the transaction logs to
rebuild a corrupted data store. That's not the same as never
corrupting the data store (which does, in fact, happen), so, since
you're giving the benefit of the doubt to the server back end, I'm
giving the same to Jet.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
I must confess that I am slightly out of my depth trying to follow this
tread. But am I correct is thinking the receieved wisdom so far here
is:
a) Access2000 is fine.
Anything beyond Access2000 is no faster/no more reliable and may not be
worth upgrading to (unless you need the new features)
b) For larger installations use SQL.
(not sure what this would be involved to do this - does a good enough
version of SQL come with Access? [Jet something or other??] Or are you
better to buy some other engine er "middleware"[??] - sorry to ask
dumb questions)
c) Split the database.
For increased speed and stability the database should be "split" so
that each user has a copy of all the forms locally.
Correct so far?
But what about OUTLOOK?!
We use msOutlook extensively - including to do mailshots to our
customers. (Database size c. 30K).
Outlook seems to be extremely slow to run and always has to be helped
though this process because it keeps crashing as it creates the
outgoing emails.
Aside: Outlook's search facility is absolute garbage. Slow,
counter-intuitive and without syntax!! But I get round this by using
Google Desktop which finds everything in a trice.
Personally I *hate* msOutlook with a passion. I find the entire system
particularly the menuing structures massively counter-intuitive.
Furthermore the Rules for sorting out the emails seem to have bugs in
them. (e.g. Try filtering incoming emails on contact Group!)
I also have the problem of having one machine that is already running
MS Office2002, whereas the rest of our PCs in the office (ie. c.10
machines) are still running MSOffice2000. I work part time in two
physical places, on two different PCs. So I simply copy my entire
"mailbox.pst" file from one machine to another (using an iPod FWIW!).
This more or less works. BUT the big problem is that the RULES always
seem to get corrupted whenever I copy between two machines and have to
be re-entered more or less from scratch.
So... even if MSAccess2002/2003 is not better than Access2000, I guess
we were hoping that the corresponding Outlook versions might be better.
Our local harward/software supplier want to sting us about GBP65 *per*
*PC* (!!), plus the MSAccess2003 software cost. We certainly can't
afford GBP600 for... ...essentially nothing - so forget that!
But maybe if we could install MSAccess2003 *ourselves* to save money
(or possibly MSAccess2002? to save further money), then that would be
worth doing.
The risk here is that our entire business now hinges on this ms Access
database, and if the upgrade goes wrong in anyway then
we would be in quite a lot of trouble!
==> Any thoughts?
Ship
Shiperton Henethe
Hi,
a) yes
b) yes, Office comes with a cut down version of SQL server called the MSDE,
it is downloadable and free from MS it comes with no developer tools, and
you are expected to do all your development work within Access, or you can
purchase the developer edition of SQL server reasobly cheap, or the full SQL
version I don't know the price but it works out expensive once you start
adding CAL's (client access licences).
c) in a multi-user environment, always split the database, for performance
and reliability reasons.
Well I think you can see my view on Outlook, great as a end-user email
manager, absolutly usless as an intergrated emailing system within a
automated application. I have written several mailers that send anything
from 1 - 50,000 emails per go, for these systems to work, skip Outlook it
just does not have the mucle to do the job, writting a socket application
that communicates directly with an SMTP server is the best solution here.
Outlook 2003 is the best version of Outlook by far, I have many clients that
are running the latest version of Outlook with previous versions of Access,
one of the major problems with Outlook integration is this the data is
unstructured by design, Access on the other hand is structured data e.g.
open a table in access and every record has the same fields, this is not the
case with Outlook, each email/contact/others can have a different record
structure making life very difficult from a programming perspective.
The other problem with using Outlook is this send a large bulk email from
outlook, and your exchange server will get very upset with the workload.
Then try to find out who got the email and who did not, yes can be done but
difficult.
Your software vendor wants to charge you £65 per computer to install Office
2003 or is that price selling you a copy of the software?
So you have 11 workstations, how many servers?
what Operating System software do you have on the server(s)?
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"ship" <sh*****@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com... I must confess that I am slightly out of my depth trying to follow this
tread. But am I correct is thinking the receieved wisdom so far here
is:
a) Access2000 is fine.
Anything beyond Access2000 is no faster/no more reliable and may not be
worth upgrading to (unless you need the new features)
b) For larger installations use SQL.
(not sure what this would be involved to do this - does a good enough
version of SQL come with Access? [Jet something or other??] Or are you
better to buy some other engine er "middleware"[??] - sorry to ask
dumb questions)
c) Split the database.
For increased speed and stability the database should be "split" so
that each user has a copy of all the forms locally.
Correct so far?
But what about OUTLOOK?!
We use msOutlook extensively - including to do mailshots to our
customers. (Database size c. 30K).
Outlook seems to be extremely slow to run and always has to be helped
though this process because it keeps crashing as it creates the
outgoing emails.
Aside: Outlook's search facility is absolute garbage. Slow,
counter-intuitive and without syntax!! But I get round this by using
Google Desktop which finds everything in a trice.
Personally I *hate* msOutlook with a passion. I find the entire system
particularly the menuing structures massively counter-intuitive.
Furthermore the Rules for sorting out the emails seem to have bugs in
them. (e.g. Try filtering incoming emails on contact Group!)
I also have the problem of having one machine that is already running
MS Office2002, whereas the rest of our PCs in the office (ie. c.10
machines) are still running MSOffice2000. I work part time in two
physical places, on two different PCs. So I simply copy my entire
"mailbox.pst" file from one machine to another (using an iPod FWIW!).
This more or less works. BUT the big problem is that the RULES always
seem to get corrupted whenever I copy between two machines and have to
be re-entered more or less from scratch.
So... even if MSAccess2002/2003 is not better than Access2000, I guess
we were hoping that the corresponding Outlook versions might be better.
Our local harward/software supplier want to sting us about GBP65 *per*
*PC* (!!), plus the MSAccess2003 software cost. We certainly can't
afford GBP600 for... ...essentially nothing - so forget that!
But maybe if we could install MSAccess2003 *ourselves* to save money
(or possibly MSAccess2002? to save further money), then that would be
worth doing.
The risk here is that our entire business now hinges on this ms Access
database, and if the upgrade goes wrong in anyway then
we would be in quite a lot of trouble!
==> Any thoughts?
Ship
Shiperton Henethe
"ship" <sh*****@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
<snip> The risk here is that our entire business now hinges on this ms Access
database, and if the upgrade goes wrong in anyway then
we would be in quite a lot of trouble!
In that case, there's really only one thing to do - test your app, with a
copy of the data, under Access 2003 in a test environment before you even
think about rolling it out company-wide. Don't get me wrong, most upgrades
go smoothly. But if the business depends on the app, don't take chances, not
even small ones.
--
Brendan Reynolds (MVP)
"Alex White MCDBA MCSE" <al**@intralan.co.uk> ¼¶¼g©ó¶l¥ó·s»D:e2****************@TK2MSFTNGP14.phx .gbl... Hi David,
I totally agree, that is the point I was trying to make, out there in the
field amongst the user base there is the perception that the latest
version is going to be faster/more reliable I know that is not true, in my
personal view what made Access 2000 a 'better' (for want of a better word)
was suddenly the integration into SQL seemed much deeper. I inherit most
of my work from other programmers who seem to have run out of steam, their
excuse for their inability to deliver a working system was to blame the
version of Access. The most important thing to a good running Access
database power of the computers that it runs on, and that they are
reliable. The point I was trying to make is proven by my never advising on
Access 2002 or 2003 unless there is a compelling reason. We all have those
jobs where they are compacting a repair a bit too often, e.g. one a day,
last year I had one such client 1.4GB data, 15 concurrent users, running
Access 2000, all I did in that situation (as they were an SBS client,
fully entitled to SQL) was upsize the back-end to SQL, no one has had to
get involved in that system since. Having used every version of Access my
favourites being v2,v97,v2000 it is horses for courses.
So in complete agreement with you,
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86... "Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#R**************@TK2MSFTNGP14.phx.gbl:
In nearly all the upgrades that I have done from Access 97 to 2000
(+) have been sold on Access 97 being unstable e.g. databases
crashing etc, the interesting thing that keeps on coming out of
these upgrades is there is some form of data corruption, of course
upgrading did not solve this problem and the data had to be
cleaned, so there is an argument that the upgrade did not make
things anymore stable.
Who is advising an upgrade from Access97 to Access2K to increase
stability? Only someone who is incompetent and has never really used
both versions to any extent would be fool enough to think that A2K
was *more* stable than A97.
The other point: if the upgrade is in response to instability
issues, anything that's causing instability in A97 is going to cause
instability in A2K (or any later version of Access), and it will
probably be worse.
There are perfectly valid reasons for upgrading.
Stability is not one of them, ever.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Larry Linson" <bo*****@localhost.not> ¼¶¼g©ó¶l¥ó·s»D:%2****************@TK2MSFTNGP09.phx .gbl... "Alex White MCDBA MCSE" wrote
Having used every version of Access my
favourites being v2,v97,v2000
it is horses for courses.
See my comments re: v2000 in comp.databases.ms-access in this thread. My
posting host for USENET doesn't carry all the microsoft.public.newsgroups.
"David W. Fenton" <dX********@bway.net.invalid> ¼¶¼g©ó¶l¥ó·s»D:Xn********************************* *@24.168.128.86... "Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#R**************@TK2MSFTNGP14.phx.gbl:
In nearly all the upgrades that I have done from Access 97 to 2000
(+) have been sold on Access 97 being unstable e.g. databases
crashing etc, the interesting thing that keeps on coming out of
these upgrades is there is some form of data corruption, of course
upgrading did not solve this problem and the data had to be
cleaned, so there is an argument that the upgrade did not make
things anymore stable.
Who is advising an upgrade from Access97 to Access2K to increase
stability? Only someone who is incompetent and has never really used
both versions to any extent would be fool enough to think that A2K
was *more* stable than A97.
The other point: if the upgrade is in response to instability
issues, anything that's causing instability in A97 is going to cause
instability in A2K (or any later version of Access), and it will
probably be worse.
There are perfectly valid reasons for upgrading.
Stability is not one of them, ever.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Alex White MCDBA MCSE" <al**@intralan.co.uk> ¼¶¼g©ó¶l¥ó·s»D:%2****************@TK2MSFTNGP12.phx .gbl... Hi Larry,
Read your comments, it is interesting the different views we all have,
The funny thing for me is this, I wrote an Access 2000 ADP project in 1999
and with permission from MS I was allowed to deploy this application
before the release of Office 2000, this application has run faultlessly
since deployment and none of the service packs were applied in response to
specific problems, more out of the client insisting that they have the
latest SP's something that I have no control over. I would go as far as to
say that in the 13 years I have been developing Access applications it
could be said that, the specific application has had more man hours of
users beating it in every direction given it is run by 150+ users 6 days a
week and the whole business relies up on it and I don't ever get phone
calls to support it, ok the data is stored in SQL7 and that does make a
difference in high volume/large amounts of concurrent users.
I am interested in what makes Access 2000 not a good product, I do agree
with Access 95 I had all sorts of problems with that.
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"Larry Linson" <bo*****@localhost.not> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... "Alex White MCDBA MCSE" wrote
> Having used every version of Access my
> favourites being v2,v97,v2000
> it is horses for courses.
See my comments re: v2000 in comp.databases.ms-access in this thread. My
posting host for USENET doesn't carry all the
microsoft.public.newsgroups.
"David W. Fenton" <dX********@bway.net.invalid> ¼¶¼g©ó¶l¥ó·s»D:Xn********************************* *@24.168.128.86... "(PeteCresswell)" <x@y.z.invalid> wrote in
news:ff********************************@4ax.com:
Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions -
which I've seen be a major problem if/when something in the LAN
environment is not right.
But that happens very, very seldom. I've only seen actual corruption
to the point of data loss a couple of times in 10 years of Access
development (all Jet back ends). And that happened in only two
different kinds of cases:
1. the client was doing no maintenance on the db at all, and storing
it on a workstation running unstable software that was constantly
crashing. The most memorable of these was back in the days of
Win3.x, and the client was running WordPerfect 6.0 on the
workstation where the Access 2 data file was stored.
2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
who did lose 3 records to corruption, ones that couldn't be
recovered after a corrupted primary key index.
I also once corrupted a client's database by running a huge append
operation against the live data file, and then killing the Access
process. I intended to run it against test data, but made a mistake.
My second mistake was killing the process. The file had to be sent
to Peter Miller for recovery and all the data was recovered.
I currently have a client with an unreliable network who is getting
"disk or network error" messages frequently, and they have not as
yet experienced any corruption of their replicated Jet 3.5 back end.
So, I'd say that Jet is not all the prone to corruption at all.
Of course, I'm defining corruption to be restricted to
non-recoverable corruption, since the only reason server databases
don't lose data is because you can run the transaction logs to
rebuild a corrupted data store. That's not the same as never
corrupting the data store (which does, in fact, happen), so, since
you're giving the benefit of the doubt to the server back end, I'm
giving the same to Jet.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"David W. Fenton" <dX********@bway.net.invalid> ¼¶¼g©ó¶l¥ó·s»D:Xn********************************* *@24.168.128.86... "Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#1**************@TK2MSFTNGP09.phx.gbl:
I'm glad I asked the question now, because in both instances I
don't have the problems that both of you have experienced, for one
I believe that Outlook is one of the worst programs that MS ever
wrote, . . .
As an Internet email client, yes, it's garbage. And given its
dependencies on IE, it's pretty insecure. But. . .
. . . and I never have anything to do with it in a programming
sense I fully understand the issues with SP3 in office as I
support more than 4000+ desktops with varying applications, got
loads of workarounds. . . .
Well, I'm not the sysadmin for all of my clients, so I don't get to
choose whether or not they use Outlook. Thus, I have to recommend
the least invasive procedures for getting Access to run safely. And
that means NO SERVICE PACK 3 for those who are using Outlook, unless
the client decides they want to apply it themselves.
If I were in control, they wouldn't be using Outlook at all!
. . . I have completely written my own emailing
functions that I have been using for years now due to my complete
lack of respect for Outlook for anything other than a simple email
front-end. . . .
It sucks as a standalone email client.
It is only a good program when used in conjunction with Exchange
Server, where you get lots of useful functionality that just isn't
there in the standalone configuration.
. . . The Jet engine is great and I have many programs out
there in the field that just run and run, where I feel it lacks is
in high volume data/users and in those situations it's a SQL
back-end every time, but I have been doing that with every version
of Access, it's just with 2000 (or better) SQL was better
integrated. . . .
This is of no use to developers like me who don't develop apps to
run against SQL Server. If you did more pure-Jet development, you'd
be just as wary of Access 2000.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Alex White MCDBA MCSE" <al**@intralan.co.uk> ¼¶¼g©ó¶l¥ó·s»D:%2****************@TK2MSFTNGP09.phx .gbl... Hi David and Peter,
I'm glad I asked the question now, because in both instances I don't have
the problems that both of you have experienced, for one I believe that
Outlook is one of the worst programs that MS ever wrote, and I never have
anything to do with it in a programming sense I fully understand the
issues with SP3 in office as I support more than 4000+ desktops with
varying applications, got loads of workarounds. I have completely written
my own emailing functions that I have been using for years now due to my
complete lack of respect for Outlook for anything other than a simple
email front-end. The Jet engine is great and I have many programs out
there in the field that just run and run, where I feel it lacks is in high
volume data/users and in those situations it's a SQL back-end every time,
but I have been doing that with every version of Access, it's just with
2000 (or better) SQL was better integrated. As I said in an earlier post
it is interesting the different views/experiences we all have personally I
am not happy with either of the newer versions of Access beyond 2000 and I
struggle to find compelling reasons to upgrade to either from Access 2000.
I have a working solution that does it for me every time, Windows2000
Server/Windows2003 Server WinXP SP2 clients, Office 2000 With SP3, Latest
MDAC's latest Critical Updates, and on bigger installations SQL 2000, I
put these jobs in a don't here about any problems with my work, if
anything I phone them every 5-6 months asking if it is all going well.
With respect our views differ, but that what these newsgroups are about,
if we all thought the same, then just one person could answer all the
questions.
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"(PeteCresswell)" <x@y.z.invalid> wrote in message
news:ff********************************@4ax.com... Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions - which
I've seen
be a major problem if/when something in the LAN environment is not right.
--
PeteCresswell
"ship" <sh*****@yahoo.com>
???????:11**********************@g44g2000cwa.googl egroups.com... I must confess that I am slightly out of my depth trying to follow this
tread. But am I correct is thinking the receieved wisdom so far here
is:
a) Access2000 is fine.
Anything beyond Access2000 is no faster/no more reliable and may not be
worth upgrading to (unless you need the new features)
b) For larger installations use SQL.
(not sure what this would be involved to do this - does a good enough
version of SQL come with Access? [Jet something or other??] Or are you
better to buy some other engine er "middleware"[??] - sorry to ask
dumb questions)
c) Split the database.
For increased speed and stability the database should be "split" so
that each user has a copy of all the forms locally.
Correct so far?
But what about OUTLOOK?!
We use msOutlook extensively - including to do mailshots to our
customers. (Database size c. 30K).
Outlook seems to be extremely slow to run and always has to be helped
though this process because it keeps crashing as it creates the
outgoing emails.
Aside: Outlook's search facility is absolute garbage. Slow,
counter-intuitive and without syntax!! But I get round this by using
Google Desktop which finds everything in a trice.
Personally I *hate* msOutlook with a passion. I find the entire system
particularly the menuing structures massively counter-intuitive.
Furthermore the Rules for sorting out the emails seem to have bugs in
them. (e.g. Try filtering incoming emails on contact Group!)
I also have the problem of having one machine that is already running
MS Office2002, whereas the rest of our PCs in the office (ie. c.10
machines) are still running MSOffice2000. I work part time in two
physical places, on two different PCs. So I simply copy my entire
"mailbox.pst" file from one machine to another (using an iPod FWIW!).
This more or less works. BUT the big problem is that the RULES always
seem to get corrupted whenever I copy between two machines and have to
be re-entered more or less from scratch.
So... even if MSAccess2002/2003 is not better than Access2000, I guess
we were hoping that the corresponding Outlook versions might be better.
Our local harward/software supplier want to sting us about GBP65 *per*
*PC* (!!), plus the MSAccess2003 software cost. We certainly can't
afford GBP600 for... ...essentially nothing - so forget that!
But maybe if we could install MSAccess2003 *ourselves* to save money
(or possibly MSAccess2002? to save further money), then that would be
worth doing.
The risk here is that our entire business now hinges on this ms Access
database, and if the upgrade goes wrong in anyway then
we would be in quite a lot of trouble!
==> Any thoughts?
Ship
Shiperton Henethe
"(PeteCresswell)" <x@y.z.invalid>
???????:ff********************************@4ax.com ... Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions - which
I've seen
be a major problem if/when something in the LAN environment is not right.
--
PeteCresswell
"Alex White MCDBA MCSE" <al**@intralan.co.uk> ¼¶¼g©ó¶l¥ó·s»D:OZ**************@TK2MSFTNGP12.phx.g bl... David,
Thank you for you comments, read both of your posts, the difference
between your thoughts and mine are not worlds apart, we both live in the
real world not the one that MS prescribes for us (I am an MCDBA,MCSE the
company that I own is a MS gold Partner so I don't take my relationship
lightly with MS), but I will stand up and be counted on a number of
issues related to their products. What I will say in their defence is
this, they strive to make the best software products in the world, and
when they are clearly behind they will try a partnership or buyout, I have
no problem with that, they also DO listen to what people want, sometimes
that can take a couple of versions, I am prepared to wait. I will stand
here and say I totally believe that Access is one of the best (if not the
best) product(s) they have ever been involved in. As a programmer in a
number of different systems (only one not MS being perl currently) I am in
the business in providing solutions to my clients that solution has to be
based on a few points, functionality, reliability, cost (some people think
this is the most important point, they all learn the hard way), speed of
delivery.
What the point of my reply is this,
A good database design is everything, without it, walk away from the
project, stability is in the foundations not the front-end, Normalizing to
3NF seems to produce the best all round results (base on time/cost). I
came from the DBase III world, Clipper (Still got loads running in the
field) Access was a revolution to me. I will stand by my original
statement about Access 2000 as all of my clients (that I have provided
Access 2000 solutions too) are still with me and they don't think I have
had them.
In my humble view the only database that don't suffer the corruptions (at
the level) of MDB's are network level DB's like SQL as they are far more
robust due to network level transactions. Nearly all the true file level
databases corruptions I have seen could be associated with poor networks
etc not specific versions of Access. This is not me saying the products
are without fault, it's understanding the faults.
Good to speak....
I will respect others views, I may not agree with them.
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86... "(PeteCresswell)" <x@y.z.invalid> wrote in
news:ff********************************@4ax.com:
Per Alex White MCDBA MCSE:
ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions -
which I've seen be a major problem if/when something in the LAN
environment is not right.
But that happens very, very seldom. I've only seen actual corruption
to the point of data loss a couple of times in 10 years of Access
development (all Jet back ends). And that happened in only two
different kinds of cases:
1. the client was doing no maintenance on the db at all, and storing
it on a workstation running unstable software that was constantly
crashing. The most memorable of these was back in the days of
Win3.x, and the client was running WordPerfect 6.0 on the
workstation where the Access 2 data file was stored.
2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
who did lose 3 records to corruption, ones that couldn't be
recovered after a corrupted primary key index.
I also once corrupted a client's database by running a huge append
operation against the live data file, and then killing the Access
process. I intended to run it against test data, but made a mistake.
My second mistake was killing the process. The file had to be sent
to Peter Miller for recovery and all the data was recovered.
I currently have a client with an unreliable network who is getting
"disk or network error" messages frequently, and they have not as
yet experienced any corruption of their replicated Jet 3.5 back end.
So, I'd say that Jet is not all the prone to corruption at all.
Of course, I'm defining corruption to be restricted to
non-recoverable corruption, since the only reason server databases
don't lose data is because you can run the transaction logs to
rebuild a corrupted data store. That's not the same as never
corrupting the data store (which does, in fact, happen), so, since
you're giving the benefit of the doubt to the server back end, I'm
giving the same to Jet.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Brendan Reynolds" <br******@discussions.microsoft.com> ¼¶¼g©ó¶l¥ó·s»D:ec**************@TK2MSFTNGP15.phx.g bl...
"ship" <sh*****@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
<snip> The risk here is that our entire business now hinges on this ms Access
database, and if the upgrade goes wrong in anyway then
we would be in quite a lot of trouble!
In that case, there's really only one thing to do - test your app, with a
copy of the data, under Access 2003 in a test environment before you even
think about rolling it out company-wide. Don't get me wrong, most upgrades
go smoothly. But if the business depends on the app, don't take chances,
not even small ones.
--
Brendan Reynolds (MVP)
"Alex White MCDBA MCSE" <al**@intralan.co.uk> ¼¶¼g©ó¶l¥ó·s»D:%2****************@TK2MSFTNGP15.phx .gbl... Hi,
a) yes
b) yes, Office comes with a cut down version of SQL server called the
MSDE, it is downloadable and free from MS it comes with no developer
tools, and you are expected to do all your development work within Access,
or you can purchase the developer edition of SQL server reasobly cheap, or
the full SQL version I don't know the price but it works out expensive
once you start adding CAL's (client access licences).
c) in a multi-user environment, always split the database, for performance
and reliability reasons.
Well I think you can see my view on Outlook, great as a end-user email
manager, absolutly usless as an intergrated emailing system within a
automated application. I have written several mailers that send anything
from 1 - 50,000 emails per go, for these systems to work, skip Outlook it
just does not have the mucle to do the job, writting a socket application
that communicates directly with an SMTP server is the best solution here.
Outlook 2003 is the best version of Outlook by far, I have many clients
that are running the latest version of Outlook with previous versions of
Access, one of the major problems with Outlook integration is this the
data is unstructured by design, Access on the other hand is structured
data e.g. open a table in access and every record has the same fields,
this is not the case with Outlook, each email/contact/others can have a
different record structure making life very difficult from a programming
perspective.
The other problem with using Outlook is this send a large bulk email from
outlook, and your exchange server will get very upset with the workload.
Then try to find out who got the email and who did not, yes can be done
but difficult.
Your software vendor wants to charge you ?5 per computer to install Office
2003 or is that price selling you a copy of the software?
So you have 11 workstations, how many servers?
what Operating System software do you have on the server(s)?
--
Regards
Alex White MCDBA MCSE
http://www.intralan.co.uk
"ship" <sh*****@yahoo.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...I must confess that I am slightly out of my depth trying to follow this
tread. But am I correct is thinking the receieved wisdom so far here
is:
a) Access2000 is fine.
Anything beyond Access2000 is no faster/no more reliable and may not be
worth upgrading to (unless you need the new features)
b) For larger installations use SQL.
(not sure what this would be involved to do this - does a good enough
version of SQL come with Access? [Jet something or other??] Or are you
better to buy some other engine er "middleware"[??] - sorry to ask
dumb questions)
c) Split the database.
For increased speed and stability the database should be "split" so
that each user has a copy of all the forms locally.
Correct so far?
But what about OUTLOOK?!
We use msOutlook extensively - including to do mailshots to our
customers. (Database size c. 30K).
Outlook seems to be extremely slow to run and always has to be helped
though this process because it keeps crashing as it creates the
outgoing emails.
Aside: Outlook's search facility is absolute garbage. Slow,
counter-intuitive and without syntax!! But I get round this by using
Google Desktop which finds everything in a trice.
Personally I *hate* msOutlook with a passion. I find the entire system
particularly the menuing structures massively counter-intuitive.
Furthermore the Rules for sorting out the emails seem to have bugs in
them. (e.g. Try filtering incoming emails on contact Group!)
I also have the problem of having one machine that is already running
MS Office2002, whereas the rest of our PCs in the office (ie. c.10
machines) are still running MSOffice2000. I work part time in two
physical places, on two different PCs. So I simply copy my entire
"mailbox.pst" file from one machine to another (using an iPod FWIW!).
This more or less works. BUT the big problem is that the RULES always
seem to get corrupted whenever I copy between two machines and have to
be re-entered more or less from scratch.
So... even if MSAccess2002/2003 is not better than Access2000, I guess
we were hoping that the corresponding Outlook versions might be better.
Our local harward/software supplier want to sting us about GBP65 *per*
*PC* (!!), plus the MSAccess2003 software cost. We certainly can't
afford GBP600 for... ...essentially nothing - so forget that!
But maybe if we could install MSAccess2003 *ourselves* to save money
(or possibly MSAccess2002? to save further money), then that would be
worth doing.
The risk here is that our entire business now hinges on this ms Access
database, and if the upgrade goes wrong in anyway then
we would be in quite a lot of trouble!
==> Any thoughts?
Ship
Shiperton Henethe
"ship" <sh*****@yahoo.com> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com: But what about OUTLOOK?!
My view of it is that if you're not using Outlook with Exchange
Server then you shouldn't be using Outlook at all, since the whole
design is tied to Exchange and its capabilities. The Outlook
defaults and behavior and UI for Internet email suck and always
have, plus there's the dependency on IE (in rendering email and in
the UI), which makes it vulnerable to exploits in software outside
itself.
I've used Outlook in Exchange environments and it's really a
completely different program than standalone Outlook.
I long ago stopped thinking that automating Outlook from Access was
a good idea. It simply didn't work well enough to be worth the
effort. However, I never attempted it in an Exchange environment,
where it very well may work better.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#r**************@TK2MSFTNGP15.phx.gbl: I have written several mailers that send anything
from 1 - 50,000 emails per go, for these systems to work, skip
Outlook it just does not have the mucle to do the job, writting a
socket application that communicates directly with an SMTP server
is the best solution here. . . .
Aren't you running into problems with spam filters? I've given up on
sending email from a client PC, since it will end up trash-canned by
any ISP that uses one of the RBLs to classify mail as spam. I think
the only remaining viable way to send mass email is through mailing
lists.
. . . Outlook 2003 is the best version of
Outlook by far, I have many clients that are running the latest
version of Outlook with previous versions of Access, one of the
major problems with Outlook integration is this the data is
unstructured by design, Access on the other hand is structured
data e.g. open a table in access and every record has the same
fields, this is not the case with Outlook, each
email/contact/others can have a different record structure making
life very difficult from a programming perspective.
Well, every record *does* have the same fields, it's just that some
of them mean different things in different item types, and every
item type uses only a subset of the whole class of fields. It's a
very non-normalized data store, and using it from Access takes a
very definite change of mindset, at least for me.
My main problem with automating Outlook from Access is *speed*.
Because you're basically doing sequential access on non-indexed
recordsets, it's *very* slow with data sets of any size whatsoever.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Mass mailing is something to be done cautiously, when ever I provide a
solution to a client, Un-announced emails are a real problem in world wild
web, and I don't condone it at all, all my clients are using opt in systems,
with opt out systems for people that don't want the emails anymore. The
biggest problem with RBL's is Reverse NDR spamming and not real spammers. I
think RBL's are going to be a thing of the past soon, with SPF records in
DNS going to become the standard soon.
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.90... "Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#r**************@TK2MSFTNGP15.phx.gbl:
I have written several mailers that send anything
from 1 - 50,000 emails per go, for these systems to work, skip
Outlook it just does not have the mucle to do the job, writting a
socket application that communicates directly with an SMTP server
is the best solution here. . . .
Aren't you running into problems with spam filters? I've given up on
sending email from a client PC, since it will end up trash-canned by
any ISP that uses one of the RBLs to classify mail as spam. I think
the only remaining viable way to send mass email is through mailing
lists.
. . . Outlook 2003 is the best version of
Outlook by far, I have many clients that are running the latest
version of Outlook with previous versions of Access, one of the
major problems with Outlook integration is this the data is
unstructured by design, Access on the other hand is structured
data e.g. open a table in access and every record has the same
fields, this is not the case with Outlook, each
email/contact/others can have a different record structure making
life very difficult from a programming perspective.
Well, every record *does* have the same fields, it's just that some
of them mean different things in different item types, and every
item type uses only a subset of the whole class of fields. It's a
very non-normalized data store, and using it from Access takes a
very definite change of mindset, at least for me.
My main problem with automating Outlook from Access is *speed*.
Because you're basically doing sequential access on non-indexed
recordsets, it's *very* slow with data sets of any size whatsoever.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"David W. Fenton" <dX********@bway.net.invalid> ¼¶¼g©ó¶l¥ó·s»D:Xn********************************* *@24.168.128.90... "Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#g**************@TK2MSFTNGP12.phx.gbl:
I am interested in what makes Access 2000 not a good product, I do
agree with Access 95 I had all sorts of problems with that.
I don't do ADPs, nor do I ever intend to, so I don't know anything
about them beyond what I've read.
But with MDBs and Jet data sources, A2K is completely unusable in
any release before SR1 (Larry says Office SP3, but I've found that's
not necessary, nor desirable for sites using Outlook who want to
avoid the Draconian Outlook "security" "fix"), and with any version
of Jet 4 before SP6. The latter is now less of an Access-specific
issue, since Jet 4 is now shipped with the OS (since Win2K), as it
is used for storing the Active Directory database. If you've
service-packed your OS, you've already probably gotten a decent
version of Jet 4.
The problems with pre-SR1 Access and Jet 4.0 before SP6 are severe
enough that I log the versions of MSACCESS.EXE and MSJET40.DLL for
each user logon to any of may applications where I don't have full
control over the configuration of the desktops. That way I can
inform the sysadmins when a machine has reverted to a bad version of
Access 2K.
The problems with Jet 4.0 before SP6 were quite severe, real
show-stoppers.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
adsl wrote: "Alex White MCDBA MCSE" <al**@intralan.co.uk> ¼¶¼g©ó¶l¥ó·s»D:%2****************@TK2MSFTNGP09.phx .gbl...
Hi David and Peter,
Ummm, is it my newsreader or does all this adsl person do is reply
quoting the text of the post to which s/he is responding?
It looks as if s/he is trying to participate but in all posts from this
person I don't see anything except quoted text?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86... "(PeteCresswell)" <x@y.z.invalid> wrote in
news:ff********************************@4ax.com:
Per Alex White MCDBA MCSE:ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions -
which I've seen be a major problem if/when something in the LAN
environment is not right.
But that happens very, very seldom. I've only seen actual corruption
to the point of data loss a couple of times in 10 years of Access
development (all Jet back ends). And that happened in only two
different kinds of cases:
1. the client was doing no maintenance on the db at all, and storing
it on a workstation running unstable software that was constantly
crashing. The most memorable of these was back in the days of
Win3.x, and the client was running WordPerfect 6.0 on the
workstation where the Access 2 data file was stored.
2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
who did lose 3 records to corruption, ones that couldn't be
recovered after a corrupted primary key index.
I also once corrupted a client's database by running a huge append
operation against the live data file, and then killing the Access
process. I intended to run it against test data, but made a mistake.
My second mistake was killing the process. The file had to be sent
to Peter Miller for recovery and all the data was recovered.
I currently have a client with an unreliable network who is getting
"disk or network error" messages frequently, and they have not as
yet experienced any corruption of their replicated Jet 3.5 back end.
So, I'd say that Jet is not all the prone to corruption at all.
Of course, I'm defining corruption to be restricted to
non-recoverable corruption, since the only reason server databases
don't lose data is because you can run the transaction logs to
rebuild a corrupted data store. That's not the same as never
corrupting the data store (which does, in fact, happen), so, since
you're giving the benefit of the doubt to the server back end, I'm
giving the same to Jet.
Ok, I usually lurk, but I have some questions about corruption. I've read
that the databases should be split, with data on the network, and the forms
and queries on each individual pc. We use Acess 97, not split, but with no
queries or forms. All of the user input and queries are done through
programs written in Visual C++ 6.0. The database lives on the network, the
programs live on each users' PC. I didn't write the actual database code,
so I assume it uses JET. It doesn't use ODBC. Most of the users have XP,
but a few still have Win98, so when I do get a chance to make changes in the
code, I compile it for both, and have separate installs. I do a compact and
repair on the databases about once a month, when everyone else has gone
home. The databases are small: the largest is about 30-35MB.
We get corruption, oh, maybe once a year or so. The network is slow
perhaps, then they start getting error messages. I kick everyone out, and
see records with #ERROR all across. I've recovered the data by copying
everything to Excel in the bad database, and then copying it back. (I've
got to do some funky stuff, since there are autonumber fields to deal with
as well.) We always lose a few records. Last week we had corruption, and
the repair wouldn't work, so I restored from backup. I then tried a repair
from 2002, and it did work (converting the database as well), so I managed
to give them some of the data they had entered. Some was still lost.
So, other than not having enough time to work on this project, and not
knowing exactly how the database access* works, what am I doing wrong? I
don't like any corruption, but it still occasionally happens. Do I need a
split database when the database only has tables? Tell me more about
transaction logs to rebuild corrupted data stores. (I don't usually have
physical access to the computer the data resides on, just a network map to
the drive.)
-k
*access, not Access. Although I certainly don't know exactly how the
database Access works either!
Looks like the work of a virus-infected computer.
Immanuel Sibero
"Tim Marshall" <TI****@PurplePandaChasers.Moertherium> wrote in message
news:d6**********@coranto.ucs.mun.ca... adsl wrote:
"Alex White MCDBA MCSE" <al**@intralan.co.uk>
¼¶¼g©ó¶l¥ó·s»D:%2****************@TK2MSFTNGP09.phx .gbl...Hi David and Peter,
Ummm, is it my newsreader or does all this adsl person do is reply
quoting the text of the post to which s/he is responding?
It looks as if s/he is trying to participate but in all posts from this
person I don't see anything except quoted text?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Hi Karen,
You do not need to split your database, splitting is the process of moving
the data away from everything else in an mdb file, in your situation, you
are using the mdb as a data store only. The fact that your front-end is C++
would normally indicate a pretty good programmer as they have used (In my
opinion) the hardest language to master outside of assembler. I would make
sure you are running the latest MDAC/Jet stuff http://www.microsoft.com/data
make sure your computers are patched and in good working order.
--
Regards
Alex White MCDBA MCSE http://www.intralan.co.uk
"karen" <no*****************@ix.netcomspamnot.com> wrote in message
news:Yr***********@bcandid.telisphere.com...
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@24.168.1 28.86... "(PeteCresswell)" <x@y.z.invalid> wrote in
news:ff********************************@4ax.com:
Per Alex White MCDBA MCSE:
ok the data is stored in SQL7 and that does make a difference in
high volume/large amounts of concurrent users.
I'd also say that it makes it immune to backend DB corruptions -
which I've seen be a major problem if/when something in the LAN
environment is not right.
But that happens very, very seldom. I've only seen actual corruption
to the point of data loss a couple of times in 10 years of Access
development (all Jet back ends). And that happened in only two
different kinds of cases:
1. the client was doing no maintenance on the db at all, and storing
it on a workstation running unstable software that was constantly
crashing. The most memorable of these was back in the days of
Win3.x, and the client was running WordPerfect 6.0 on the
workstation where the Access 2 data file was stored.
2. in Access 2000, before the arrival of Jet 4 SP6, I had one client
who did lose 3 records to corruption, ones that couldn't be
recovered after a corrupted primary key index.
I also once corrupted a client's database by running a huge append
operation against the live data file, and then killing the Access
process. I intended to run it against test data, but made a mistake.
My second mistake was killing the process. The file had to be sent
to Peter Miller for recovery and all the data was recovered.
I currently have a client with an unreliable network who is getting
"disk or network error" messages frequently, and they have not as
yet experienced any corruption of their replicated Jet 3.5 back end.
So, I'd say that Jet is not all the prone to corruption at all.
Of course, I'm defining corruption to be restricted to
non-recoverable corruption, since the only reason server databases
don't lose data is because you can run the transaction logs to
rebuild a corrupted data store. That's not the same as never
corrupting the data store (which does, in fact, happen), so, since
you're giving the benefit of the doubt to the server back end, I'm
giving the same to Jet.
Ok, I usually lurk, but I have some questions about corruption. I've read
that the databases should be split, with data on the network, and the
forms and queries on each individual pc. We use Acess 97, not split, but
with no queries or forms. All of the user input and queries are done
through programs written in Visual C++ 6.0. The database lives on the
network, the programs live on each users' PC. I didn't write the actual
database code, so I assume it uses JET. It doesn't use ODBC. Most of the
users have XP, but a few still have Win98, so when I do get a chance to
make changes in the code, I compile it for both, and have separate
installs. I do a compact and repair on the databases about once a month,
when everyone else has gone home. The databases are small: the largest is
about 30-35MB.
We get corruption, oh, maybe once a year or so. The network is slow
perhaps, then they start getting error messages. I kick everyone out, and
see records with #ERROR all across. I've recovered the data by copying
everything to Excel in the bad database, and then copying it back. (I've
got to do some funky stuff, since there are autonumber fields to deal with
as well.) We always lose a few records. Last week we had corruption, and
the repair wouldn't work, so I restored from backup. I then tried a
repair from 2002, and it did work (converting the database as well), so I
managed to give them some of the data they had entered. Some was still
lost.
So, other than not having enough time to work on this project, and not
knowing exactly how the database access* works, what am I doing wrong? I
don't like any corruption, but it still occasionally happens. Do I need a
split database when the database only has tables? Tell me more about
transaction logs to rebuild corrupted data stores. (I don't usually have
physical access to the computer the data resides on, just a network map to
the drive.)
-k
*access, not Access. Although I certainly don't know exactly how the
database Access works either!
On Mon, 16 May 2005 18:16:24 GMT, "karen"
<no*****************@ix.netcomspamnot.com> wrote: Ok, I usually lurk, but I have some questions about corruption. I've read
that the databases should be split, with data on the network, and the forms
and queries on each individual pc. We use Acess 97, not split, but with no
queries or forms. All of the user input and queries are done through
programs written in Visual C++ 6.0. The database lives on the network, the
programs live on each users' PC. I didn't write the actual database code,
so I assume it uses JET. It doesn't use ODBC. Most of the users have XP,
but a few still have Win98, so when I do get a chance to make changes in the
code, I compile it for both, and have separate installs. I do a compact and
repair on the databases about once a month, when everyone else has gone
home. The databases are small: the largest is about 30-35MB.
Essentailly, you already HAVE a split database: the tables in a .mdb
file on the backend, and the user interface application distributed
onto each frontend. It's only different in that your frontend is
implemented in VC++ rather than in Access. You'll get no benefit from
splitting since basically there is nothing to split!
We get corruption, oh, maybe once a year or so. The network is slow
perhaps, then they start getting error messages. I kick everyone out, and
see records with #ERROR all across. I've recovered the data by copying
everything to Excel in the bad database, and then copying it back. (I've
got to do some funky stuff, since there are autonumber fields to deal with
as well.) We always lose a few records. Last week we had corruption, and
the repair wouldn't work, so I restored from backup. I then tried a repair
from 2002, and it did work (converting the database as well), so I managed
to give them some of the data they had entered. Some was still lost.
Hm. I don't see clearly how going to Excel buys you anything! In that
situation I'd be inclined to a) keep good current backups and simply
trash the corrupt database and simply recover from the backup; b) have
a routine of Compacting the database (you may well be doing so); and
c) if necessary, create a brand-new empty database and use File... Get
External Data... Import to import all the tables. For a damaged table
it may be necessary to create the table empty, Link to the damaged
table, and run one or more Append queries to migrate the data.
So, other than not having enough time to work on this project, and not
knowing exactly how the database access* works, what am I doing wrong? I
don't like any corruption, but it still occasionally happens. Do I need a
split database when the database only has tables? Tell me more about
transaction logs to rebuild corrupted data stores. (I don't usually have
physical access to the computer the data resides on, just a network map to
the drive.)
Transaction logs are available natively in SQL/Server, but not in
Access JET databases. They can be implemented in JET but it would be a
REALLY big painful job - simpler to install MSDE and move the data to
SQL!
It may well be worth your while to check out Tony's excellent FAQ at http://www.granite.ab.ca/access/corruptmdbs.htm
for suggestions to prevent (or at least inhibit) corruption.
John W. Vinson[MVP]
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in
news:#f**************@TK2MSFTNGP09.phx.gbl: Mass mailing is something to be done cautiously, when ever I
provide a solution to a client, Un-announced emails are a real
problem in world wild web, and I don't condone it at all, all my
clients are using opt in systems, with opt out systems for people
that don't want the emails anymore. The biggest problem with RBL's
is Reverse NDR spamming and not real spammers. I think RBL's are
going to be a thing of the past soon, with SPF records in DNS
going to become the standard soon.
The client for whom I created a mass mailing system was entirely
opt-in, so that had nothing to do with it. I would not have done the
work if I was not assured of that.
The problems were manyfold:
1. their ISP put in place a requirement that emails had a limit of
25 recipients (we were using BCC back in those old days of spam
innocence!).
2. we first switched to indivual emails, but their ISP eventually
throttled their SMTP connections and wouldn't allow them to send
more than X number of email messages in a particular period (I
forget the exact number and the exact period).
3. we then switched to batches of 25 in the BCC, and that has
worked. However:
4. lots of ISP's spam filters mark their mailings as spam because:
a. 25 addresses in the BCC
b. sent from a dynamic IP.
So, they are now using CoolerMail.com to send the announcement of
their quarterly newsletter. I really do think that class of service
is the only alternative nowadays.
Fortunately, it's very easy for them to export the temp table I was
using to drive the mass emailing from Access.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"karen" <no*****************@ix.netcomspamnot.com> wrote in
news:Yr***********@bcandid.telisphere.com: We get corruption, oh, maybe once a year or so. The network is
slow perhaps, then they start getting error messages. I kick
everyone out, and see records with #ERROR all across. I've
recovered the data by copying everything to Excel in the bad
database, and then copying it back. (I've got to do some funky
stuff, since there are autonumber fields to deal with as well.)
We always lose a few records. Last week we had corruption, and
the repair wouldn't work, so I restored from backup. I then tried
a repair from 2002, and it did work (converting the database as
well), so I managed to give them some of the data they had
entered. Some was still lost.
You must have a network problem somewhere, or your program is doing
something not kosher with managing connections. Or somebody is
shutting off their PC with a pending edit (though whether or not
that can corrupt your data depends entirely on how it's implemented
in the app).
The problem you described sounds like lost memo field pointers. Two
things to do:
1. change the memo fields to text fields, if the data will fit.
2. make sure the app uses no "bound" methods for editing memos.
I'm not sure how a C++ application would implement this, but when
implementing it in Access, the crucial idea is that the user edits
an unbound control that was populated in code and then the changes
are posted via SQL that updates the underlying record. If the
programmer used any advanced add-in controls that offered any kind
of data binding, this might be the source of the problem.
Also, you might try sending a corrupted MDB to Peter Miller at
PKSolutions.com -- he can recover just about anything.
So, other than not having enough time to work on this project, and
not knowing exactly how the database access* works, what am I
doing wrong? I don't like any corruption, but it still
occasionally happens. Do I need a split database when the
database only has tables? Tell me more about transaction logs to
rebuild corrupted data stores. (I don't usually have physical
access to the computer the data resides on, just a network map to
the drive.)
The comment about transaction logs was about SQL Server, not Jet,
which doesn't have (and couldn't possibly ever have) such a thing.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"karen" <no*****************@ix.netcomspamnot.com> wrote in message
news:Yr***********@bcandid.telisphere.com...
Ok, I usually lurk, but I have some questions about corruption. I've read
that the databases should be split, with data on the network, and the
forms and queries on each individual pc. We use Acess 97, not split, but
with no queries or forms. All of the user input and queries are done
through programs written in Visual C++ 6.0. The database lives on the
network, the programs live on each users' PC. I didn't write the actual
database code, so I assume it uses JET. It doesn't use ODBC. Most of the
users have XP, but a few still have Win98, so when I do get a chance to
make changes in the code, I compile it for both, and have separate
installs. I do a compact and repair on the databases about once a month,
when everyone else has gone home. The databases are small: the largest is
about 30-35MB.
We get corruption, oh, maybe once a year or so. The network is slow
perhaps, then they start getting error messages. I kick everyone out, and
see records with #ERROR all across. I've recovered the data by copying
everything to Excel in the bad database, and then copying it back. (I've
got to do some funky stuff, since there are autonumber fields to deal with
as well.) We always lose a few records. Last week we had corruption, and
the repair wouldn't work, so I restored from backup. I then tried a
repair from 2002, and it did work (converting the database as well), so I
managed to give them some of the data they had entered. Some was still
lost.
So, other than not having enough time to work on this project, and not
knowing exactly how the database access* works, what am I doing wrong? I
don't like any corruption, but it still occasionally happens. Do I need a
split database when the database only has tables? Tell me more about
transaction logs to rebuild corrupted data stores. (I don't usually have
physical access to the computer the data resides on, just a network map to
the drive.)
-k
*access, not Access. Although I certainly don't know exactly how the
database Access works either!
Thank you all for the advice. I was thinking that maybe my setup meant that
I essentially already had a split database. It's nice to know that is the
case. So, for preventative measures, I should:
-- check the versions of MDAC used, and make sure it is up to date
everywhere.
-- make sure systems are up to date in general (A couple are Win98 still).
-- Remind people to always close this application before shutting down.
We do have a memo field, but a text field isn't big enough. I'm not sure
what a bound method for editing memos is, but I bet I can google that.
When I do get corruption I can:
-- make a new database and use File...Get External Data to import the data,
skipping the Excel step. (That sounds good.)
-- If all else fails, restore from backup.
-- blame the network! I often do that anyway. :) It may not be fair, but
it's convenient, especially since they often say it is slow right before it
chokes.
And refer to http://www.granite.ab.ca/access/corruptmdbs.htm for clues and
reminders.
-karen
Tim Marshall <TI****@PurplePandaChasers.Moertherium> wrote: Ummm, is it my newsreader or does all this adsl person do is reply
quoting the text of the post to which s/he is responding?
It's not you. I see the same thing.
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
"David W. Fenton" <dX********@bway.net.invalid> wrote: 3. we then switched to batches of 25 in the BCC, and that has
worked. However:
4. lots of ISP's spam filters mark their mailings as spam because:
a. 25 addresses in the BCC
Trouble is the only time the ISP would know if there are multiple
address in the BCC are if they are to the same host. Your email
server should be splitting out the email to each individual host.
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
"Alex White MCDBA MCSE" <al**@intralan.co.uk> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl... Hi Larry,
Read your comments, it is interesting the different views we all have,
Yes, it is interesting... for a number of years I worked on a client
company's Access 2.0 client to an Informix database. As I am sure you know,
the only option was Access-Jet-ODBC-serverDB. When I last worked on it, it
was happily supporting between 175 - 200 users. I've worked on Access 97
DBs, similarly configured, but not with quite so many users.
There have been numerous detailed reports here of problems with early
versions of Access 2000, and with early versions of ADP. My experience is
that applying all the Service Packs and Jet updates makes Access 2000
reasonably solid and stable. But in Michael Kaplan's words, "I'd rather
slide down a giant razor blade into a vat of iodine than undertake a
development project with an unupdated Access 2000." Particularly given that
it is now "out of support".
My limited experience with ADP was, indeed, in maintaining and enhancing an
application with Access 2000 SP1. I did not run into serious problems, but
it was an unusual-design application. The original author had neither bound
any forms, nor defined primary keys on the SQL Server 2000 tables that it
accessed. I saw no advantage to ADP over using MDB and ODBC, either in
stability nor performance.
Larry Linson
Microsoft Access MVP This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Lauren Wilson |
last post by:
Hi Folks,
I have a widely distributed Access 200 Application. I must retain my
ability to support users who are still on Access 2000 and Access 2000
Runtime. However I also need to upgrade my...
|
by: Owen Jenkins |
last post by:
I have an Access application that is being used by 150+ clients. I
develop in 97, convert to 2000 and distribute as a 97 or 2000 mde, or 97
runtime. This limits me to 97 functions. My clients may...
|
by: JohnH |
last post by:
I'm just recently come to work for an auto brokerage firm. My
position involves performing mysterious rites, rituals and magick in
order to get information out of their access database. This is...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
