How to create field A= field C * fied B

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

you can't LINK to that function, you can only IMPORT it

with SQL Server, you keep your FUNCTIONS and QUERIES and TABLES where
they belong-- on a database SERVER. So that anyone can use new queries
without a new build.
It allows you to do a lot more dynamic development-- changing a query
in production without putting out a new build?

PRICELESS

you can't be serious- about stacking queries on top of queries.
for starters-- having too many columns-- it's just not practical to be
limited to joining FIVE TABLES with FIFTY COLUMNS each.

I should be able to write larger joins than that.

Jet just has too many limits-- no real reason to use a crap database
that has MORE MAINTENANCE and is thus MORE EXPENSIVE.
yes-- compressed XML is a step in the right direction-- but it's still
no where near as compact as SQL Server compression.

Jet just doesn't integrate with Microsofts Enterprise Level Business
Intelligence products.
It makes no sense to have a database that doesn't play with the big-
boys toys


Jet just isn't fast enough.

I had to generate a list of every possible zipcode today.. and I ran a
simple simple simple script.. to populate 100,000 records into a
table, a single column.

SQL Server took 384 seconds.
and JET took 970 seconds.

the exact exact exact same scenario-- except Jet took 3 times longer
to run.

I see that same ratio on everything I do.

JET IS THREE TIMES SLOWER THAN SQL SERVER.
AND TEN TIMES HARDER TO DEVELOP AND MAINTAIN.

Flat Out Bull Shit That Stacking Queries On Top Of Queries Works.

Let's agree on a testing methodology, ok?

We'll cooperate and run some tests- to show people 'just how nifty'
Access queries really are.

SOUND GOOD?

-Aaron

 

[So Sorry For Poor Aaron]

You're like a bulldog, aren't you? You just won't let go. You keep grasping
at straws, and exaggerating, and lying to try to support something that you
knew better than to write in the first place.

You are, indeed, as has been said before "A SAD, SAD EXCUSE FOR A HUMAN
BEING."

You just didn't get to spend enough time with Big Bruce, Big Bubba, and Big
Barney for them to continue your education on being polite, and respecting
your betters (which would be 'everyone').

So Sorry For The Poor Bulldog-Boy

 

[Arvin Meyer [MVP]]

Rolling out a front-end to a few dozen workstations is as trivial as logging
in.

So you're saying that you work in a production environment, instead of on a
test bed. That really is priceless, and probably not true because no
self-respecting IT department would ever let you do that. Every enterprise
level IT department that I ever worked with insisted that any changes were
rolled out during non-peak hours, usually after normal working hours, and
tested again before allowing it into production.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


message
you can't LINK to that function, you can only IMPORT it

with SQL Server, you keep your FUNCTIONS and QUERIES and TABLES where
they belong-- on a database SERVER. So that anyone can use new queries
without a new build.
It allows you to do a lot more dynamic development-- changing a query
in production without putting out a new build?

PRICELESS

 

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

dude I can copy the database and change my file, connection in a
single place
SQL Server is just 10 times easier to manage.. specifically in
deployment, implementation.. _DEVELOPMENT_, troubleshooting.

Jet doesnt' have a profiler.
and more importantly-- JET CORRUPTS

why dont' your WTFU until they fix that

 

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

whatever kid.

SQL Server is better and cheaper.
Just because you should have upgraded a decade ago-- doesn't mean you
don't NEED to upgrade today
Just because you should have upgraded a decade ago-- doesn't mean you
don't NEED to upgrade today
Just because you should have upgraded a decade ago-- doesn't mean you
don't NEED to upgrade today