Splitting Database Didn't Fix It

[David W. Fenton]

"a a r o n . k e m p f @ g m a i l . c o m" <[email protected]>
wrote in
m:

Honestly-- Splitting is not the reccomended move-- and it hasnt'
been for a decade.

You are so full of horseshit.

In any event, you don't do Jet development, so how the hell would
you have any idea what are best practices for Access/Jet
applications?

You can't even get it right when posting recommendations about
Access used with SQL Server, your claimed area of expertise!

 

[David W. Fenton]

"a a r o n . k e m p f @ g m a i l . c o m" <[email protected]>
wrote in
m:

Just upsize to SQL Server...

This makes it quite clear that you're not actually interested in
contributing anything that helps the original poster solve his/her
problems. If you were, you would have read the actual thread and you
would have known that the OP is already using SQL Server as the back
end data store.

You look pretty stupid recommending that he/she do what he/she is
already doing.

Of course, you look pretty stupid in general.

This particular instance of your stupidity makes it clear that
you're just looking for posts from certain people that mention
certain of your hot-button topics and responding to those not to
solve problems but just to stir up shit.

Can't you find a hobby that doesn't make such a mess for other
people?

 

[David W. Fenton]

I'm fairly certian I'm not running on SQL Server.
I don't know what exactly I'm running on, but I'm pretty sure
it's not SQL
Server. That might account for the CREATE TABLE error I get when
I use CREATE VIEW syntax.

No, that doesn't necessarily indicate anything. It may be that you
are running as a user that doesn't have permission to create
tables/views.

 

[David W. Fenton]

I copied and pasted that in the immediate window (After replacing
"Name...Here" with a table inside the database) and pressed Enter,
and nothing happened. I also tried putting it inside a MsgBox
within the Sub and I got a blank message box.
Curiouser and curiouser...

Are you using ODBC for the connection? Do you have linked tables?
Are you running the command in the front end MDB?

 

[So Sorry For Poor Aaron]

SubQ is actually an ALIAS for the employees table
I name tables in all my subqueries SubQ, SubQ2, SubQ3, etc

Certainly, you are trying to obscure the fact that you know less than
nothing about what you are being paid to do, so you use a naming convention
that is meaningless, content-free. Aren't you one who was bragging about how
clear your naming convention is? What a POC you are.

It is a sin and a shame that you are denser than spent uranium and just
can't realize it. Poor rattlebrain, numbskull aaron.

So Sorry Than Anyone Has to be So Stupid

 

[a a r o n _ k e m p f]

if they used ADP, they wouldn't have to bother about

a) connection strings
b) DAO - an obscure, obsolete DAL attached to a dead engineless
database
c) create view syntax- they could build a view where it says 'design
view'

I'm not stupid.

I'm not the one that takes a database that CORRUPTS and reccomends it
over a superior database WITH EASIER DEVELOPMENT.

SQL Server is just plain better, bigger, faster _AND_ easier than JET.
and it's cheaper.

It auto-shrinks.

Does JET?

It includes a job scheduling engine.

DOES JET?

Go and stick a fork in a light socket; retard

 

[a a r o n _ k e m p f]

and what _EXACTLY_ are you referring to, btw?

I've never given a false or wrong answer on SQL Server.
and yes-- I've done more JET dev than any of the dipshits in this
channel, for sure.

Just because i've seen the light-- and I give a shit enough -- to come
back and save the unsaved-- doesn't make me wrong.
Just because i've seen the light-- and I give a shit enough -- to come
back and save the unsaved-- doesn't make me wrong.
Just because i've seen the light-- and I give a shit enough -- to come
back and save the unsaved-- doesn't make me wrong.
Just because i've seen the light-- and I give a shit enough -- to come
back and save the unsaved-- doesn't make me wrong.

 

[a a r o n _ k e m p f]

yah no shit you haven't made a view in SQL Server. You're a MVP.
Which means that you're a crybaby that can't tie your shoes without
navigating through the 'linked table manager'.

No wonder you give false information-- constantly reccomending JET
over SQL Server

YOU HAVE NEVER USED SQL SERVER, SO LISTEN TO ME OLD MAN-- DON'T EVER
RECCOMEND SHIT AGAINST SQL SERVER BECAUSE YOU HAVE NEVER BUILT A VIEW.

Newbies learning SQL Server should build a view-- that's the first
thing that they should do.
And you haven't even done that?

Go and play with Excel you fucking loser.

-Aaron

 

[Author]

I feel out of my league when you ask such questions. In the most logical
terms I can manage, I'll briefly explain how it is set up (mind you, I didn't
create it. I'm just a guy trying to make life a little easier). There are
three "linked tables" that "talk to" a computer program (ManMan, in fact) and
retrieve copious amounts of data. Users run a report (with a query as its
source data) about 50 times a day, and each time they run the report it
filters through all three of these "linked tables" (which are actually the
result of Access talking to ManMan). Now, these "linked tables" were
referred to as ODBC by my boss- whether that's right or not, I can't say.
The only table that I attempted to link between the FE and BE of my split
database was a local version of the data they were viewing (I kept the query
exactly as it was, only I typed INTO tStaticDataForReportViewing so that it
would put the data into a smaller table, resulting in instant opening of the
report rather than waiting three minutes for the query to run. Brilliant,
right? <grimace>) As it turns out, that plan won't work.
Anyhow, you guys are pretty sharp with your database knowledge. I just hope
the next time I have a question I'll 1.) Know what I'm talking about and 2.)
Have a problem with a solution. It turns out I was originally running the
command in the non-split version of the database, a fact that made me feel
silly and small. Thank you all for your help.
Cheers,
Me

 

[a a r o n . k e m p f]

if you're needing to use 'temp tables' in Jet-- you'd be better off
storing your data in SQL Server

if your database was faster-- it wouldnt' need all this complexity
move to SQL Server, kid

I feel out of my league when you ask such questions.  In the most logical
terms I can manage, I'll briefly explain how it is set up (mind you, I didn't
create it.  I'm just a guy trying to make life a little easier).  There are
three "linked tables" that "talk to" a computer program (ManMan, in fact)and
retrieve copious amounts of data.  Users run a report (with a query as its
source data) about 50 times a day, and each time they run the report it
filters through all three of these "linked tables" (which are actually the
result of Access talking to ManMan).  Now, these "linked tables" were
referred to as ODBC by my boss- whether that's right or not, I can't say. 
The only table that I attempted to link between the FE and BE of my split
database was a local version of the data they were viewing (I kept the query
exactly as it was, only I typed INTO tStaticDataForReportViewing so that it
would put the data into a smaller table, resulting in instant opening of the
report rather than waiting three minutes for the query to run.  Brilliant,
right?  <grimace>)  As it turns out, that plan won't work.
Anyhow, you guys are pretty sharp with your database knowledge.  I justhope
the next time I have a question I'll 1.) Know what I'm talking about and 2.)
Have a problem with a solution.  It turns out I was originally running the
command in the non-split version of the database, a fact that made me feel
silly and small.  Thank you all for your help.
Cheers,
Me

Are you using ODBC for the connection? Do you have linked tables?
Are you running the command in the front end MDB?

 

[Author]

I'm just a temp trying to get hired on. If it were up to me, I'd consider
changing platforms/database engines. But in terms of decision-making, I'm
less than nobody. I'll run it by my boss, he'll run it by his boss, the memo
will get forwarded to headquarters in another state, yadda yadda... you get
the idea. Corporation = bureaucracy, red tape, etc.
But thanks for the suggestion!

if you're needing to use 'temp tables' in Jet-- you'd be better off
storing your data in SQL Server

if your database was faster-- it wouldnt' need all this complexity
move to SQL Server, kid

I feel out of my league when you ask such questions. In the most logical
terms I can manage, I'll briefly explain how it is set up (mind you, I didn't
create it. I'm just a guy trying to make life a little easier). There are
three "linked tables" that "talk to" a computer program (ManMan, in fact) and
retrieve copious amounts of data. Users run a report (with a query as its
source data) about 50 times a day, and each time they run the report it
filters through all three of these "linked tables" (which are actually the
result of Access talking to ManMan). Now, these "linked tables" were
referred to as ODBC by my boss- whether that's right or not, I can't say.
The only table that I attempted to link between the FE and BE of my split
database was a local version of the data they were viewing (I kept the query
exactly as it was, only I typed INTO tStaticDataForReportViewing so that it
would put the data into a smaller table, resulting in instant opening of the
report rather than waiting three minutes for the query to run. Brilliant,
right? <grimace>) As it turns out, that plan won't work.
Anyhow, you guys are pretty sharp with your database knowledge. I just hope
the next time I have a question I'll 1.) Know what I'm talking about and 2.)
Have a problem with a solution. It turns out I was originally running the
command in the non-split version of the database, a fact that made me feel
silly and small. Thank you all for your help.
Cheers,
Me

Are you using ODBC for the connection? Do you have linked tables?
Are you running the command in the front end MDB?

 

[a a r o n . k e m p f]

you don't have to run shit by anyone.

upsize to SQL Server, get it working-- demo that it's 4 times faster
at _EVERYTHING_ and then you'll get a perm job

 

[David W. Fenton]

I'm just a temp trying to get hired on. If it were up to me, I'd
consider changing platforms/database engines. But in terms of
decision-making, I'm less than nobody. I'll run it by my boss,
he'll run it by his boss, the memo will get forwarded to
headquarters in another state, yadda yadda... you get the idea.
Corporation = bureaucracy, red tape, etc. But thanks for the
suggestion!

Aaron's suggestion is worthless, as he has the same piece of advice
for every problem posted in this newsgroup. I mean *every* problem,
no matter whether switching to a SQL Server back end would plausibly
have any effect whatsoever on situation.

 

[a a r o n . k e m p f]

are you SERIOUSLY trying to imply that SQL Server wouldn't fix his
'problem Splitting Database Didn't Fix It'??

SQL Server is _SIMPLER_ for anything that any of you do on a daily
basis.
SQL Server compacts / repairs _AUTOMAGICALLY_.
SQL Server build sub-indexes _AUTOMAGICALLY_ (they're called
statistics)
SQL Server utilizes memory _AUTOMAGICALLY_ to make queries faster.
SQL Server doesn't require linking to FOUR TIERS of Jet Databases.
SQL Server doesn't make you copy objects around.

ADP are much much much simpler than your JET crap

stop spreading mis-information, lamer

 

[George Hepworth]

You are aware, I assume, that "AUTOMAGICALLY" is a made up word?

message
are you SERIOUSLY trying to imply that SQL Server wouldn't fix his
'problem Splitting Database Didn't Fix It'??

SQL Server is _SIMPLER_ for anything that any of you do on a daily
basis.
SQL Server compacts / repairs _AUTOMAGICALLY_.
SQL Server build sub-indexes _AUTOMAGICALLY_ (they're called
statistics)
SQL Server utilizes memory _AUTOMAGICALLY_ to make queries faster.
SQL Server doesn't require linking to FOUR TIERS of Jet Databases.
SQL Server doesn't make you copy objects around.

ADP are much much much simpler than your JET crap

stop spreading mis-information, lamer

 

[a a r o n . k e m p f]

apparently; if you think that it's not a real word-- you haven't met
the beauty of 'auto shrink' in SQL server

You are aware, I assume, that "AUTOMAGICALLY" is a made up word?

messageare you SERIOUSLY trying to imply that SQL Server wouldn't fix his
'problem Splitting Database Didn't Fix It'??

SQL Server is _SIMPLER_ for anything that any of you do on a daily
basis.
SQL Server compacts / repairs _AUTOMAGICALLY_.
SQL Server build sub-indexes _AUTOMAGICALLY_ (they're called
statistics)
SQL Server utilizes memory _AUTOMAGICALLY_ to make queries faster.
SQL Server doesn't require linking to FOUR TIERS of Jet Databases.
SQL Server doesn't make you copy objects around.

ADP are much much much simpler than your JET crap

stop spreading mis-information, lamer

innews:[email protected]:

Aaron's suggestion is worthless, as he has the same piece of advice
for every problem posted in this newsgroup. I mean *every* problem,
no matter whether switching to a SQL Server back end would plausibly
have any effect whatsoever on situation.

 

[Larry Linson]

Mr. Kempf, you know nothing about what I have worked with except what I have
written. Perhaps you are both developer and DBA in your environment, but let
me assure you that is not nearly always, or even frequently, the case in the
real world.

This is an unmoderated newsgroup, and if you wish to order other posters
around, you should found another where you are the moderator.

You _are_ an irritating, obnoxious, insulting poster with a juvenile
attitude -- no wonder you attract so many responders who answer you in the
same tone and language.

Larry Linson
Microsoft Office Access MVP
(which means something far different than what you claim,
in re which, any poster can visit http://mvp.support.microsoft.com
for details)


yah no shit you haven't made a view in SQL Server. You're a MVP.
Which means that you're a crybaby that can't tie your shoes without
navigating through the 'linked table manager'.

No wonder you give false information-- constantly reccomending JET
over SQL Server

YOU HAVE NEVER USED SQL SERVER, SO LISTEN TO ME OLD MAN-- DON'T EVER
RECCOMEND SHIT AGAINST SQL SERVER BECAUSE YOU HAVE NEVER BUILT A VIEW.

Newbies learning SQL Server should build a view-- that's the first
thing that they should do.
And you haven't even done that?

Go and play with Excel you fucking loser.

-Aaron

 

[a a r o n . k e m p f]

didn't you admit you had never built a view?

I'm just saying:

DON'T reccomend against SQL Server
unless you're a certified
MCITP: DBA
MCITP: Developer
MCITP: BI Developer

Because 90% of the time out here-- Jet crybabies try to discourage
people from moving to SQL Server.

That is just ridiculous.

90% of the people out there would be better served- using ADP instead
of JET through SQL Server.

So when you nigger loving lying dipshits _STOP_ giving false
information-- on every corner-- trying to blatantly DISCOURAGE people
from moving to SQL Server?

Access is just a speedbump on the information highway.
Does SalesForce.com integrate with Access? Do they use Access?

Because SQL Server sure does

 

[a a r o n _ k e m p f]

you don't think that this kid could get a perm job if he upsized a
database from Access to SQL ?

why don't you go to your boss and say "I DARE YOU" to let me upsize
this to SQL Server. Give me a month and it will run ten times better.

Most managers would bite on this- ESPECIALLY if it is an important
line of business app.

I work for a large company and everything that we do-- comes from SQL
Server. IT JUST WORKS.
I've built enterprise level reporting applcations for a half dozen
large employers in Seattle

How do large companies get there?

BECAUSE THEY CHOOSE A PLATFORM WITH A FUTURE.

Building little apps- nickel and dimes- just a waste of time.
I can build the same app that Access kids do.. in SQL Server-- for the
same price.

-Aaron