Re: MySQL

[Banana fanna fo fanna]

Ah. Thanks.

Grok, y'know, I'm starting to see where you're coming from with this ASP.NET + SQL Server vs PHP + MySQL.

Overall, I think ASP.NET + SQL Server would kick the shit out of PHP+MySQL for stuff like Amazon.com, while something like sclegacy.com or a lesser volume site would be well suited to PHP/MySQL since it's cheap, fast, and easy.

[Grok]

Easy now, or I'll +1 you.

[Banana fanna fo fanna]

Well in that case...

ASP SUCKS! FREEBSD FOR LYFE!!!!!!!!!!!!!! DIE BILL DIE

[Yoni]

*roasts St0rm*

[Camel]

Open up MS Access and create a couple dummy tables. Then go and mess with the queries. Queries basicly do the same thing as stored procedures (and are treated as stored procedures, as well).

[Grok]

Open up MS Access and create a couple dummy tables. Then go and mess with the queries. Queries basicly do the same thing as stored procedures (and are treated as stored procedures, as well).

To someone taking their first look at the SQL language, what you say could appear to be true.  Stored procedures are not just queries though, they are actually procedures.  They can take a number of parameters, call other functions and procedures, including extended procedures, and have conditional, branching, and looping constructs available for getting the job done.  Their return can be multiple values as well as multiple rowsets and other objects.

In addition, stored procedures are typically precompiled by the host database, so that they use the most efficient optimization in the execution plan.  Simple text queries like you have in MS Access only scratch the surface of stored procedures abilities.

[Camel]

Access has VBA -- customized functions can be used in queries. Not as good as stored procedures, but just as much can be accomplished.

[edit] BTW, Bump!

[Grok]

Camel, I have used VB and MS-Access since 1994, and SQL since 1996.

Just as much cannot be accomplished with any query passed from a client, except if that call is CREATE PROCEDURE.  In that case, you are creating a stored procedure and no longer using client-sided queries.

Stored procedures provide the complete ability of the server to the programmer.

Try writing a single MS-Access query that deletes 500 rows that are older than 30 days, until there is nothing else old enough to delete, then exits, returning the number of rows deleted.

Now imagine writing that one query to do similar, but not the same work, to 25 tables.  Add transactions to that and your query has no chance.  But it is still trivial in a stored procedure.

Did you take the SQL courses at the URLs I posted last month?  If not, you really should.  I think your eyes would be opened to the power of server-side SQL programming when you use that training in stored procedures.

SQL Books Online is the best reference you could ever need.  It's probably the most useful and complete work produced by Microsoft for any of their products.

[Camel]

One could write a VBA function to do all of that. Then, "SELECT myfunction(columns) FROM tables;"
I specificly said this method is not as practical (I used the word 'good') as stored procedures are. My point was that it's possible to do in Access, as you alluded that it was impossible.

[Grok]

One could write a VBA function to do all of that. Then, "SELECT myfunction(columns) FROM tables;"
I specificly said this method is not as practical (I used the word 'good') as stored procedures are. My point was that it's possible to do in Access, as you alluded that it was impossible.

That is precisely my contention -- that there are things possible to do in stored procedures that are impossible to do in a SELECT statement in MS-Access.

[Camel]

Conclusion: MS Access queries are the retarded siblings of stored procedures.

[Adron]

That is precisely my contention -- that there are things possible to do in stored procedures that are impossible to do in a SELECT statement in MS-Access.

If it's possible to write and use a VBA function like that in MS Access, then it seems to me that you cannot do anything more in a MSSQL SELECT than what you can do in an Access SELECT. It wouldn't surprise me if it's actually easier to do some things with an Access SELECT, like, say, putting up a GUI asking the user for input.

[Camel]

Very true. In fact, if you use a variable that doesn't exist, it will pop up an input box with the name of the variable and a text box, expecting you to type in the value. I used this a while back when I wrote a database for someone in charge of enrolling customers in different courses. Queries for reports looked something like:

SELECT * FROM Courses, Customers INNER JOIN Events ON (Courses.ID = Events.EventID) AND (Customers.ID = Events.CustomerID) WHERE Courses.CourseName LIKE [Enter course name];