J
John W. Vinson
Thank you Mary - and good to see you here!
Stolen for future postings, with attribution of course.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Thank you Mary - and good to see you here!
Stolen for future postings, with attribution of course.
A
ANDRE BLIEKENDAAL
John W. Vinson said:Thank you Mary - and good to see you here!
Stolen for future postings, with attribution of course.
A
aaron.kempf
dude don't listen to these jet losers
if you want to do what your boss says-- move to a client-server
environment.. then you don't have a choice but to move to Access Data
Projects
Jet linked tables don't work well enough.. they scan the whole table
across the network, instead of performing the appropriate-- serverside
join
if you want to do what your boss says-- move to a client-server
environment.. then you don't have a choice but to move to Access Data
Projects
Jet linked tables don't work well enough.. they scan the whole table
across the network, instead of performing the appropriate-- serverside
join
M
Mary Chipman [MSFT]
No need for attribution ;-) If you find any good links that aren't on
the list, ping me and I'll add them to my list. I usually cherry pick
messages with upsize, migrate or SQL Server in the header, and then I
just copy/paste the links from a txt file. I figure presenting all of
the available resources up front saves time for everyone involved
since people's needs and experience vary so widely.
-- Mary
the list, ping me and I'll add them to my list. I usually cherry pick
messages with upsize, migrate or SQL Server in the header, and then I
just copy/paste the links from a txt file. I figure presenting all of
the available resources up front saves time for everyone involved
since people's needs and experience vary so widely.
-- Mary
T
Tony Toews [MVP]
Mary Chipman said:No need for attribution ;-) If you find any good links that aren't on
the list, ping me and I'll add them to my list. I usually cherry pick
messages with upsize, migrate or SQL Server in the header, and then I
just copy/paste the links from a txt file.
FWIW Newsgroup Answers MDB - I designed the MDB to assist frequent newsgroup
answerers, such as MVPs, in quickly locating and pasting in their favourite snippets
of answers. http://www.granite.ab.ca/access/newsgroupanswersmdb.htm
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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
A
aaron.kempf
Jeff,
**** you ****
he wants to upsize to sQL Server, shut the **** up and don't try to
scare him away from it.
Just because Jeff Boyce is a ****ing retard-- and he listens to
dipshits like TOny Toews-- that doesn't mean that SQL Server isn't the
best solution for this OP.
He's asking how to upsize.
Why don't you go and find some Jet crybaby, you ****ing pussy loser
dipshit Jet poser?
-aaron
**** you ****
he wants to upsize to sQL Server, shut the **** up and don't try to
scare him away from it.
Just because Jeff Boyce is a ****ing retard-- and he listens to
dipshits like TOny Toews-- that doesn't mean that SQL Server isn't the
best solution for this OP.
He's asking how to upsize.
Why don't you go and find some Jet crybaby, you ****ing pussy loser
dipshit Jet poser?
-aaron
A
aaron.kempf
I'd reccomend using Access 2002 or 2003 with sQL 2000.. or Access 2007
with SQL 2005
with SQL 2005
A
aaron.kempf
correction
MOVing to sql server and running the database tuning advisor will
_always_always_always_ give you better performance than what is
possible with jet
MOVing to sql server and running the database tuning advisor will
_always_always_always_ give you better performance than what is
possible with jet
A
aaron.kempf
Mary;
You're a ****ing Jet loser-- why don't you shut the **** up and learn
enough about SQL Server to.. uh-- know the basics of SQL Server.
you're an uneducated **** and a ****ing jet loser.
eat a dick whore.
-Aaron
You're a ****ing Jet loser-- why don't you shut the **** up and learn
enough about SQL Server to.. uh-- know the basics of SQL Server.
you're an uneducated **** and a ****ing jet loser.
eat a dick whore.
-Aaron
A
aaron.kempf
I disagree with all your numbers.
Jet can't handle 1,000 records and 10 tables without crapping out
Jet can't handle 1,000 records and 10 tables without crapping out
A
aaron.kempf
Tony;
**** you ****-- he's asking for help in moving to SQL Server
just because you didn't have enough mental capacity-- to successfully
complete the single upsizing attempt that you made-- that doesn't mean
that it's harder.
It ust means the schools up in canada are too ****ing crappy for you
to learn how to use software
-Aaron
**** you ****-- he's asking for help in moving to SQL Server
just because you didn't have enough mental capacity-- to successfully
complete the single upsizing attempt that you made-- that doesn't mean
that it's harder.
It ust means the schools up in canada are too ****ing crappy for you
to learn how to use software
-Aaron
J
Jeff Boyce
My experience is different.
I have Access applications running with happy users and tens of thousands
of rows, on well over 20 tables.
As always seems the case, performance depends, at least in part, on the
design/implementation. It sounds like yours is different...
Regards
Jeff Boyce
Microsoft Office/Access MVP
I disagree with all your numbers.
Jet can't handle 1,000 records and 10 tables without crapping out
I have Access applications running with happy users and tens of thousands
of rows, on well over 20 tables.
As always seems the case, performance depends, at least in part, on the
design/implementation. It sounds like yours is different...
Regards
Jeff Boyce
Microsoft Office/Access MVP
I disagree with all your numbers.
Jet can't handle 1,000 records and 10 tables without crapping out
M
Mary Chipman [MSFT]
Thanks Tony -- that's a great resource for people who answer a lot of
questions.
--Mary
questions.
--Mary
T
Tony Toews [MVP]
Mary Chipman said:Thanks Tony -- that's a great resource for people who answer a lot of
questions.
You're welcome and thanks.
Do you think I sure convert that to an ADP and use SQL Server?
<smirk> (no need for reply.)
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
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
J
Jeff Boyce
Tony
I'm sure Aaron has already done that ...
Jeff
I'm sure Aaron has already done that ...
Jeff
M
Mary Chipman [MSFT]
;-)
Nah, the only thing I'd change is to delete the canned answer telling
people they're asking a question in the wrong newsgroup section. When
it comes to using Access with SQL Server, there is no single "right"
way to do anything, and, IMO, wherever one is likely to get an answer
is the right place to ask. Over the years I've seen so many people get
kicked back and forth between the different products, the SQLS people
say go ask in the Access ng's, and the Access experts say go ask
somewhere else. So if all the answerers have their own lists of
resources for things they personally aren't expert in, such as all of
the ins and outs of using Access with SQL Server, then they can just
post the list for questioners to do the research on their own.
IMO there's absolutely nothing wrong with ADPs over linked table apps
for certain business scenarios, *as long as one understands the
tradeoffs*. Many people are quite happy with them. That doesn't mean
they're the answer to every Access-SQL business need, which is where a
deeper understanding comes in that is impossible to convey in a
newsgroup or forum post.
--Mary
Nah, the only thing I'd change is to delete the canned answer telling
people they're asking a question in the wrong newsgroup section. When
it comes to using Access with SQL Server, there is no single "right"
way to do anything, and, IMO, wherever one is likely to get an answer
is the right place to ask. Over the years I've seen so many people get
kicked back and forth between the different products, the SQLS people
say go ask in the Access ng's, and the Access experts say go ask
somewhere else. So if all the answerers have their own lists of
resources for things they personally aren't expert in, such as all of
the ins and outs of using Access with SQL Server, then they can just
post the list for questioners to do the research on their own.
IMO there's absolutely nothing wrong with ADPs over linked table apps
for certain business scenarios, *as long as one understands the
tradeoffs*. Many people are quite happy with them. That doesn't mean
they're the answer to every Access-SQL business need, which is where a
deeper understanding comes in that is impossible to convey in a
newsgroup or forum post.
--Mary
K
Klaus Oberdalhoff
Hi Jeff,
i agree totally.
OK, i'm (as others here) not very long on developing with Access - my first
version was 1.1 <veg>
And i just was an MVP for MS Access from 1997 to 2005
Inspite of what troll Aaron says here, i always did update to SQL Server and
"just" used linked tables and mdb.
I never had the need to change to ADO and ADP. And my customers are happy
(not only) with the speed <and after all, that's all what counts for me at
the end>.
BUT: I always managed to handle with small / very small datasets even on
1,000,000 rows or more in the table. (Of course well designed tables with
indices etc.) I regularly create views "on the fly"
and use that views as rowsource for the data. That means: Programming with
bound fields yes, but leaving the rowsource empty and setting it via
programme after i shrinked the dataset...
If having to do with "batch-processing" i tend to use arrays instead of
record-sets for reading thru the data.
My personal feeling: This (together with using the datasheet-view in
subforms) is much more performant than each other performance "trick" in
programming i found so far.
Additional plus: You can (rather easily) switch from mdb to SQL-Server and
just concentrate "on the bottlenecks" instead of reprogramming the whole
database.
mfg
Klaus
I have Access applications running with happy users and tens of thousands
of rows, on well over 20 tables.
As always seems the case, performance depends, at least in part, on the
design/implementation. It sounds like yours is different...
i agree totally.
OK, i'm (as others here) not very long on developing with Access - my first
version was 1.1 <veg>
And i just was an MVP for MS Access from 1997 to 2005
Inspite of what troll Aaron says here, i always did update to SQL Server and
"just" used linked tables and mdb.
I never had the need to change to ADO and ADP. And my customers are happy
(not only) with the speed <and after all, that's all what counts for me at
the end>.
BUT: I always managed to handle with small / very small datasets even on
1,000,000 rows or more in the table. (Of course well designed tables with
indices etc.) I regularly create views "on the fly"
and use that views as rowsource for the data. That means: Programming with
bound fields yes, but leaving the rowsource empty and setting it via
programme after i shrinked the dataset...
If having to do with "batch-processing" i tend to use arrays instead of
record-sets for reading thru the data.
My personal feeling: This (together with using the datasheet-view in
subforms) is much more performant than each other performance "trick" in
programming i found so far.
Additional plus: You can (rather easily) switch from mdb to SQL-Server and
just concentrate "on the bottlenecks" instead of reprogramming the whole
database.
mfg
Klaus