ADP:Access >> New to SQL server

by aaron.kempf@gmail.com » Fri, 01 Dec 2006 02:51:26 GMT

yeah with MDB you have to 'write your own EVERYTHING'

with SQL Server you dont need to do this; there aren't work arounds for
everything

MDB is too buggy to use in the real world

-Aaron


onedaywhen wrote:
> XXXX@XXXXX.COM wrote:
> > > CREATE TABLE OrgChart (
> > > employeeID INTEGER NOT NULL UNIQUE,
> > > manager_employeeID INTEGER
> > > REFERENCES OrgChart (employeeID)
> > > ON DELETE SET NULL
> > > ON UPDATE CASCADE);
> >
> > wouldn't work in SQL Server since I don't have a table named OrgChart
>
> Try reading that again (hint: CREATE TABLE OrgChart...?)
>
> > how about this.. Right-Click CREATE SCRIPT for all your MDB tables and
> > queries LoL
>
> Have you seen the code it writes: proprietary syntax, weird casing,
> peppered with parens and brackets, ...yuk! I have my own tool that
> works on both Jet and SQL Server, SQL-92 standard syntax where
> possible, SQL keywords in uppercase, etc. Lovely.
>
> > dude what about when you need to split your backend into multiple files
> > because you get a single table that is approaching 1gb?
>
> I can assure you, sir, my backend does not require splitting. ROFL.
>
> Jamie.
>
> --


ADP:Access >> New to SQL server

by onedaywhen » Fri, 01 Dec 2006 18:57:53 GMT



I agree that SQL Server trumps Jet in almost every case.

DRI is a fundamental and, truth is, Jet does it better than SQL Server.
SQL Server only has to find a second path for it to choke, whereas Jet
can usually resolve them (if they can be resolved e.g. are not
circular).

Another is CHECK constraints: Jet can do table-level CHECK constraints
and are few powerful. CHECK constraints in SQL Server are column- and
row-level only, meaning you have to resort to triggers, a whole
different animal where you have to manage things manually (rolling back
transactions, raising errors, etc).

Jamie.

ADP:Access >> New to SQL server

by aaron.kempf@gmail.com » Fri, 01 Dec 2006 22:42:11 GMT

Im actually not positive that I agree with you on that; I believe that
I have some capabilites to do table level constraints.. and im not just
talking about TRIGGERS - which are obviously 10 times more powerful
than ANYTHING in the Access World.

what.. you say that you can build an audit trail?
what.. you say that you can build an audit trail?
what.. you say that you can build an audit trail?
what.. you say that you can build an audit trail?

ROFL

you fail to mention that you can build relationships in Access against
queries.. of course; i might miss that one also because I dont think
that it lets you enforce anything

one thing that SQL kills Access on is 'Rules'
I can have a 'rule' assigned to a DATATYPE and then i can re-use my
'column level constraints' in 100 different places.. and I only have to
manage the check constraint in ONE PLACE.

I can also write specail triggers, called DDL triggers that react when
someone edits a table or a view or a stored procedure for example.



-Aaron

ADP:Access >> New to SQL server

by onedaywhen » Fri, 01 Dec 2006 23:21:25 GMT


CREATE VIEW ... WITH CHECK OPTION can perform some good tricks and is
Standard SQL, unlike triggers, which don't port well i.e. if my app
supports more than one SQL product I have to have many code bases.


Yes, it's called showplan.out

...only kidding ;-)

Jamie.

ADP:Access >> New to SQL server

by aaron.kempf@gmail.com » Sat, 02 Dec 2006 00:02:35 GMT

no; I was talking about MDB queries; you can't effectively build an
audit trail in MDB

and create view with check option.. you think that is MORE PORTABLE
than a trigger?

ROFL

where do you come up with this crap

-Aaron

ADP:Access >> New to SQL server

by onedaywhen » Mon, 04 Dec 2006 16:20:20 GMT


Yes.

Try Mimer's SQL-92 validatior:

http://developer.mimer.com/validator/parser92/index.tml

Here are the results of two examples, taken straight from SQL Server
BOL:

First, WITH CHECK OPTION:

CREATE VIEW SeattleOnly
AS
SELECT c.LastName, c.FirstName, a.City, s.StateProvinceCode
FROM Person.Contact c JOIN HumanResources.Employee e ON c.ContactID =
e.ContactID
JOIN HumanResources.EmployeeAddress ea ON e.EmployeeID = ea.EmployeeID
JOIN Person.Address a ON ea.AddressID = a.AddressID
JOIN Person.StateProvince s ON a.StateProvinceID = s.StateProvinceID
WHERE a.City = 'Seattle'
WITH CHECK OPTION;

Result:

*** Transitional SQL-92 ***

Second example, a simple trigger:

CREATE TRIGGER reminder1
ON Sales.Customer
AFTER INSERT, UPDATE
AS RAISERROR ('Notify Customer Relations', 16, 10);

CREATE TRIGGER reminder1
ON Sales.Customer
^-
syntax error: ON
correction: .

AFTER INSERT, UPDATE
^
syntax error: , UPDATE
correction: ON <identifier> UPDATE

AS RAISERROR ('Notify Customer Relations', 16, 10)
^- ^-------------------------- ^- ^-^
syntax error: AS
correction: <identifier> AS
syntax error: 'Notify Customer Relations'
correction: <identifier> ) SET <identifier> = 'Notify Customer
Relations'
syntax error: 16
correction: <identifier> = 16
syntax error: 10
correction: <identifier> = 10
syntax error: ) <end>
correction: <end>

Conclusion: WITH CHECK OPTION is SQL-92 syntax whereas CREATE TRIGGER
is Microsoft proprietary syntax. SQL products are more likely to
implement standard SQL syntax, of course. Experience tells me that, in
the absence of a standard, trigger syntax between SQL products vary
quite a bit, therefore porting a trigger involves a re-write. Even the
Microsoft's proprietary syntax may be subject to change in future
versions.

Jamie.

ADP:Access >> New to SQL server

by aaron.kempf@gmail.com » Mon, 04 Dec 2006 23:03:21 GMT

dude what a joke.. where did you come up with this cracker-jax
executable

sorry that some dipshit doesn't like triggers; triggers are practical

views are not

ADP:Access >> New to SQL server

by onedaywhen » Tue, 05 Dec 2006 00:18:33 GMT


Think about it: most (all?) SQL products have the concept of VIEWs -
hey, even Access/Jet does! - and the pretty much all do the same
things. In terms of implementation considerations, adding support for
WITH CHECK OPTION would be relatively trivial. But just think what
would be required to add triggers to Access/Jet: control of flow
syntax, error handling, etc i.e. a much more difficult implementation.
And with no standard to follow, would you trust Microsoft to get it
right?

And if VIEWs are not practical in the SQL product of your choice then
it could be time for a new SQL product: they are much better in Oracle
e.g. materialized views shared across connections etc. SQL Server uses
the same model as Access/Jet i.e. basically the VIEW definition gets
copied and pasted into the query as a derived table :(

Jamie.

ADP:Access >> New to SQL server

by aaron.kempf@gmail.com » Tue, 05 Dec 2006 01:39:46 GMT

Access / JET?

Only fucking retards still use Access / JET

end of story

-Aaron

ADP:Access >> New to SQL server

by dbahooker@hotmail.com » Tue, 05 Dec 2006 02:49:01 GMT

DRI doesn't work in Access / JET

hey check this out.. from your own website

Check Your SQL Against the SQL-92 Standard. Mimer SQL-92 Validator
recognizes the standards Entry, Transitional, Intermediate and Full
SQL-92, Persistent Stored Modules (PSM) SQL-99 and Database Triggers
SQL-99.


Database Triggers SQL-99.
Database Triggers SQL-99.
Database Triggers SQL-99.
Database Triggers SQL-99.
Database Triggers SQL-99.



Triggers are the OLD WAY of enforcing DRI.. now we have real DRI... and
when things get too comples for standard DRI; we have TRIGGERS

ADP:Access >> New to SQL server

by dbahooker@hotmail.com » Tue, 05 Dec 2006 02:54:05 GMT

you're arguing that Access DRI is more powerful than SQL DRI

Access DRI just blatantly doesn't fucking work for jack shit

I think that if you hold down shift then it ignores RI ROFL
I think that if you hold down shift then it ignores RI ROFL
I think that if you hold down shift then it ignores RI ROFL
I think that if you hold down shift then it ignores RI ROFL


I mean seriously here.
you can't enforce RI against Linked tables; and every table in the
world should be a linked table.. right?

So yeah.. you can partially enforce relationships in the so-called
'backend' but whenever you make changes you hae to sent out an email
saying 'please get out of the database because mdb is for retards'

lose the training wheels; kids

-Aaron

ADP:Access >> New to SQL server

by dbahooker@hotmail.com » Tue, 05 Dec 2006 02:58:07 GMT

and for the record; who gives a flying shit for ANSI-92 compliance
anyways?

TSQL won the war; MDB is roadkill; so is Oracle and mySql

ADP:Access >> New to SQL server

by onedaywhen » Tue, 05 Dec 2006 06:51:36 GMT


Tell me: which SQL products have implemented full SQL-99? Which have
implemented SQL-99 Triggers? You think TSQL has? ROFL

Jamie.

ADP:Access >> New to SQL server

by onedaywhen » Tue, 05 Dec 2006 07:01:41 GMT


No, I am saying DRI is better implemented in Access/Jet. All SQL Server
needs to do, two versions and seven years down the line, is get their
implementation as good as Access/Jet's - I mean, how hard can that be?


That is actually funny <g>!


Linked tables..right? ROFL

Jamie.

ADP:Access >> New to SQL server

by dbahooker@hotmail.com » Tue, 05 Dec 2006 07:03:38 GMT

WHO GIVES A FLYING FUCK

TSQL IS THE STANDARD

how about measuring how well Oracle syntax meets up with TSQL?

that's more relevent.. BECAUSE MICROSOFT WON THE WAR, JACKASS