It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I have been looking to find answers to this question from past two hours. I haven't found even one single relevant post/book/answer. Could somebody explain the difference between server-side scripting and client-side scripting to me. I know that triggers are part of server-side scripting but really, whats the difference between the two. Could you please provide me with couple examples.
Thanks!
This could actually mean a couple of different things, but the explanation that is probably most relevant to you (based on your mention of triggers) is that server-side scripting is SQL that is precompiled and stored in the database in the form of triggers, functions, stored procedures, views, etc while client-side SQL (also known as dynamic SQL) is SQL that is contained within the application.
Some of the reasons for implementing server-side SQL include performance (the database can precompile and optimize the SQL), security, and maintenance (it is much easier to modify a stored procedure than to recompile and re-release your application).
The primary reason that we have found for implementing dynamic SQL is to handle situations in which are not easily handled through server-side SQL, usually involving variable-length where statements.
I don't think you can say there is really such thing as "client-side SQL". There might be SQL commands/statements generated by a client application, but they are executed directly on the Database Enginer to persist and be logged.
In other words a client application might issue this:
select *
from SomeTable
If it is successful, that SELECT will be executed on the database server, not the client application even though that's where it was generated.
Now you might be trying to distinguish where SQL code is generated. A client application might generate the bulk of the Data Manipulation Language (DML) code (i.e. INSERT/UPDATE/DELETE) and be performing OLAP (SELECT). The server will generate the SQL and events for things like triggers. The database engine, with a trigger, will see that an action was taken on a database, object, or the server itself and then this event will "trigger" the database engine to execute another piece of SQL code. That would be server-generate SQL.
I think I understand your question, but please let me know if there is something else or I didn't answer it correctly.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm looking for a way to store a result set in my SQL Server database so it's faster to retrieve, if possible. The reason I want to do this is that I need the information quite frequently, but the data rarely changes so I believe it will improve my database performance a lot.
The only thing I was able to find was indexed views, which doesn't work for me since my query doesn't qualify for that kind of view.
My result set is derived from several sql queries, that will increase in time.
My backup solution is to have the program using the database to store it's own copy, so I can skip calling the database. But this will make my system more complex. I would rather have all my data calls in the database so it's easier to keep track of things.
Do any of you know a way store result sets on a SQL Server database?
I need the information quite frequently, but the data rarely changes
If the data is going to rarely change, then why not just use a SSI file based on the data in the database. You can always recreate this text file whenever the data changes.
When I did web stuff we served up all the data for all the web pages directly from database queries. We decided to change our model to use SSI files for all the database items that rarely changed. We built a "File Recreation" routine inside the backend admin that would automatically build and overwrite the SSI file when ever the customer changed one of those "rarely" changed database items.
This boosted performance on our servers, cut down on server round trips and spead up the display time. Truly a win-win.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I don't normally deal in databases (I've managed a few small ones for web apps I wrote for me and my friends) So I'm going to verify that I understand how everything works, before asking my question.
SQL is a program that "does" databases. It manages all the tables and the schemes and the links, and it does most everything in response to commands it receives. You could type these commands in by hand, or have a script you write with commands in them, or have another program send these commands to SQL, but the commands haven't really changed.
SQL Injection occurs when a web application Takes input received from the user, and sends it to SQL without cleaning it up first. If the end-user is wiley enough, SQL will see commands that it was supposed to see as Data to be stored in a table somewhere, resulting in travesty.
Typical SQL injection prevention involves sanitizing your user input, that is, stripping out any characters that would make SQL think a command was being sent, instead of data.
Now, My question:
Why does SQL not handle this for us? Why does SQL, on each command, not look for the first ", and the last ", and ignore any "s in between? (I don't think "'s are a part of standard SQL command syntax, it's been a while, but if not, change could happen) It would, of course, prevent you from sending multiple commands simultaneously (as the 2nd/3rd commands would be ignored) but on a "I send 1 command at a time" rule, this pretty much ignores any shenanigans the end-user might try to pull.
I'm sure someone else has thought of this, and dismissed it as not working for some reason or another. But I don't know enough to understand why, and I'd like to.
"SQL" doesn't handle it for us because "SQL" isn't a program, it's a language: Structured Query Language. The applications we build to interface with databases use the language SQL as a means to retrieve information from the database.
The applications we build also use some sort of API (application programmer's interface) to talk to the database and that API passes the SQL in to the database. (Actually to the RDBMS or Relational Database Management System, which is the "program" you might be thinking of like MySQL, Oracle, MS SQL Server, or PostgreSQL)
There are some smarter APIs which do in fact handle the parameter sanitizing on their own, if the API offers access to prepared statements or stored procedure execution.
Potential trouble with SQL injection comes when the API doesn't use prepared statements or parameterized queries (or the developer elects not to use them) and instead directly constructs statements in the SQL language to pass to the database. The API's job in this instance is simple: Just take the string handed from the application and pass it to the database. Because the SQL statement itself takes no input (remember, it is just a string), it has to be up to the developer to make sure it doesn't contain harmful information.
More sophisticated APIs which offer prepared statements or parameterized queries do take input and translate the input values into placeholders in the SQL statement, either passing the information natively to the RDBMS to process the parameters and prepared statement, or emulating that action in the application code, before passing a plain SQL string to the RDBMS; part of that translation usually involves sanitizing the values against harmful characters.
I needn't go in to the misconceptions about SQL here as they are explained well in the comments.
However, SQL does provide a way to prevent against SQL Injection, known as parameterized queries. Basically, when you construct a SQL command using both preformed content (verb, clause, etc) and user-supplied input, you can do so in two ways.
You can concentrate them all together into one string. Since you're
only passing in one string, the database has to parse the whole thing
and this is where SQL injection becomes possible.
You can use parametrized statements, where you use placeholders for
user-supplied data and then specify what goes in them. When this is
passed to the database, it can see what is intended to be data and
what is intended to be command and can properly process them, thus
effectively mitigating the threat of SQL Injection (note that a
defense-in-depth strategy would still require you to properly
sanitize the inputs before you do this; I highly recommend you do
both to properly secure yourself).
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I want to know if you have ever performed injection on a website using SQL injection for ethical hacking.
What tricks/techniques have you have used (especially mysql)?
I've used the standard trick on login forms:
user: admin
pass: ' OR '1'='1
Not directly, but sometimes I do LIKE searches with wildcards (%) even though the search page does not say it supports them.
If you intend to perform ethical hacking or penetration testing of applications using MySQL, you'll find the OWASP Testing Guide, specifically the section on MySQL to be of immense value, apart from the generic Testing Guide for SQL injection.
Note that this does not make any assumptions about the framework or langauge in use - PHP, Java (including Java EE, Spring etc.), so it is pretty generic in how SQL injection may be attempted against an application. The actual techniques involved in getting the user inputs to the database access layer of the application, indeed will vary from one application to another. Applications that parse HTTP requests, will of course, require all inputs (URL parameters, name-value pairs in the POST body, HTTP headers) to be suspect. Having a different source of input (say XML or JSON instead of simple HTTP requests) will require you to feed in SQL in appropriate manner that will be understood by the application's parsers, eventually resulting in transportation of SQL to the layer where database queries are executed.
Nice infomation about techniqs for
Example :
statement = "SELECT * FROM users WHERE name = '" + userName + "';"
pass userName = ' or '1'='1
SELECT * FROM users WHERE name = '' OR '1'='1';
SQL injection
Type of it
1.2 Incorrect type handling
1.3 Vulnerabilities inside the database server
1.4 Blind SQL injection
1.4.1 Conditional responses
1.4.2 Conditional errors
1.4.3 Time delays
You just remimded this, I hope you'll find it fun:
http://xkcd.com/327/ ;)
Yes I have used the basic methods like everyone else, but always on my own websites
' OR '1'='1
I even joined a site where you can learn the basics of hacking in a website, they have put up a serie of website specially made to show the vulnerability of the website (of course you are not shown how to do it but you have to find it out for yourself). And no I feel no guilt whatsoever as I do not use it to harm other peoples website but only myne.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I want to know
how do the 3 compare with one
another?
which one to use when?
which can be used as a replacement of
other?
SQL -- generic name for the language which is used to query relational databases.
This is governed by various ANSI standards although I know of no actual RDBS which implements completely the latest standard. Several implement most of ANSI SQL - 92 which can be regarded as the lowest common denominator for SQL implementations.
PL/SQL -- An Oracle specific extension to SQL which is used to write "STORED PROCEDURES" and "TRIGGERS" its effectivly a scripting languages which can use Oracles SQL natively. In SQLServer TSQL provides similar functionality.
SQLJ -- Part of the Java standard, a (seldom used) feature which allows SQL to be coded inline with the Java code and for SQL syntax to be checked at compile time. Compare with JDBC which is a standard Java API which allows a Java program to invoke SQL at runtime.
So SQL allows basic querying and updateing of tables as in "SELEC * FROM MY.TABNAME", PL/SQL allows more intelligent scripts to be run against the database as something like " IF DAY = 01 THEN ( INSERT (TOTALS) VALUES(%VAL) INTO TOTTAB ) ELSE (UPDATE TOTTAB SET TOTALS = TOTALS + %VAL")
Regarding to your question "which one to use when". Some Oracle gurus recommend:
First try to solve your problem with plain SQL
If you can't do it with sql, then try PL/SQL
Only use other languages like Java externally of your database if you can't do it internally.
But of course you can treat your database as a dump storage of data and do all the business logic externally in a separate layer.
If the need is truly an SQL need, then I try to implement it in SQL first. There might be some specific circumstances where a PL/SQL procedural call with, perhaps a judicious use of bulk binds and bulk fetches, might be faster/cause fewer resource contentions/etc than a pure SQL solution, but that's rare in my experience.
I try to draw a distinction between "database logic" and "application logic" and while I admit it can be fuzzy sometimes, I try very hard to avoid writing application logic in PL/SQL. The reason is simply that it's far less expressive than Java and has much weaker APIs for pretty much everything except SQL interaction.
I personally don't use SQLJ, so I can't help you there, sorry.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
will FOR XML AUTO queries in stored procedures and using ExecuteXmlReader to retreive data to set business objects cause any performance hit?
I don't know about performance, but I have started doing things this way in order to take advantage of serialization, so I can pass BLL types as generics directly to the DAL for filling, and I like it a lot. It bypasses the Linq or typed DataSets, and uses a lot less code, whether machine-generated or not. As for performance, the best thing to do is run your own tests.
Update: If you're going to use FOR XML to serialize to BLL objects, don't use auto, use PATH, and specify the name of the root, otherwise it will use <row/> as the root element.
It surely affects the performance if the amount of data you are going to retrieve is relatively higher (The XML formatting is bigger than TDS rowset). I don't have the exact statistics with me. But tou can easily profile your queries with and without XML AUTO and find the facts. But XML AUTO surely takes much time than normal SQL queries.
I would say its preferrable to convert your recordsets to XML format in your application code than doing it in sql server.
EDIT:
T-SQL commands vs. XML AUTO in SQL Server - this article explains and gives the comparison between XML auto and normal T-SQL queries, have a look at this.
Author concluded that "It seem to be consistent that the T-SQL query is performing better than the rest. The XML query FOR XML AUTO is using more than eight times more CPU but the same amount of I/O. The complex XML commands are issuing more than 80 times (!) more reads than the T-SQL command, also many writes and above six times the CPU."