Thanks Ken,
Yes, I recently purchased a wonderfully written book on Access & SQL
Server
by Mary Chipman and Andy Baron. It seems to have a lot of good
information
in there, not only about integrating Access & SQL, but a striking degree
of
depth to the text also. So, I will have my work cut out over the next few
months but it should be informative and rewarding to learn these new
skills.
Thanks for all your suggestions during the course of this post, they have
been insightful and encouraging. I never fail to admire the dedication of
people such as yourself who watch over the developing flock.
Regards
--
Thanks
David G
Albury, Australia
"Ken Snell (MVP)" wrote:
> Just a guess on my part, but the message from ACCESS may have been an
> indication that the amount of data being im****ted ("changed") was
exceeding
> the buffer space that ACCESS could use and thus be able to rollback the
> im****t if a failure occurred. 256MB for an ACCESS backend is not a large
> size, but my preference would be to start looking to SQL Server or other
> large database system when the ACCESS file approaches 1.25 - 1.5GB.
Reason:
> although ACCESS can handle 2GB max size for a file, the file size grows
as
> you manipulate data in it, which compacting will shrink back down; but,
> during that interim growth, if you hit 2 GB, that will crash the
database
> file. So it's best to not get too close to the maximum size.
>
> At the rate of about 150KB of new data per day, using your numbers, you
can
> calculate how much time you have before you would hit my arbitrary size.
> --
>
> Ken Snell
> <MS ACCESS MVP>
> http://www.accessmvp.com/KDSnell/
>
>
> "David G" <jazzbah@[EMAIL PROTECTED]
> wrote in message
> news:FC24428C-4701-410E-B870-4C250E77EB67@[EMAIL PROTECTED]
> > Thanks Ken,
> >
> > Interestingly something surprising happened during the im****t of data.
At
> > about 2.6 million rows Access threw up a message saying "Your computer
is
> > running out of disk space, continue yes, no?" This kept recurring so
I
> > stopped the im****t. The mdb file was about 256mb, not very big
because
> > the
> > rows, consisting of 8 fields adding up to about 60 bytes per row.
Hard to
> > fathom. Frustrating because the im****t procedure was working so well.
I
> > definitely wasn't going to run out of space because that drive is
750gb
> > with
> > 690gb free.
> > Having just returned from the Sydney OfficeDevCon 2008, I did ask
around
> > about this but didn't get any conclusive answers.
> > One of the suggestions, due to the size that this mdb will get to, is
to
> > migrate it to SQL Server 2000. The file grows by about 2,500 rows per
> > business day. So that seems to be plausible, but doesn't answer the
> > unlikely
> > error message I received.
> > Thanks for the modified code,
> > Regards
> > --
> > Thanks
> > David G
> > Albury, Australia
>
>
>
|
