VIBE CODED

To get query string using Javascript: temp = window.location.search.substring(1); document.write( temp ); -We create a variable temp -Built-in Javascript properties:  window.location  is the entire url.  search.substring(1)  is the part after the question mark. -We  write  the value of  temp  to the browser. Below is a  function  that will break the query string into pieces for you: Copy and Paste Javascript Code: <script type="text/javascript"> <!-- function querySt(ji) { hu = window.location.search.substring(1); gy = hu.split("&"); for (i=0;i<gy.length;i++) { ft = gy[i].split("="); if (ft[0] == ji) { return ft[1]; } } } var koko = querySt("koko"); document.write(koko); document.write("<br>"); document.write(hu); --> </script>

Run the below SQL Query to get the procedure information in a database. select * from INformation_schema.routines

jQuery Demo - Expandable Sidebar Menu from John Resig on Vimeo .

Free web application called WebAnywhere for screen reader web accessibility tests to simulate how a person using a screen reader will interact with your content. http://webanywhere.cs.washington.edu/ 

Never  might sound like a long time, but prefixing your procedure names with sp_ causes a performance penalty if the procedures exist in a database other than master. Don't do it. The example that  Listing 1  shows illustrates why you should never prefix procedures with sp_ if you intend to use them in a high-volume transaction-processing environment while maintaining the best possible performance. The code in Listing 1 creates two test procedures in tempdb. I named the first procedure Select1 and the second procedure sp_Select1. The procedures run an identical command, SELECT 1, which is the simplest SELECT statement imaginable. Run each of the procedures once, as  Listing 2  shows, to ensure that SQL Server has compiled the procedure plans for each procedure and has cached them in memory. Then, proceed through the following steps to see the performance implication of prefixing procedures with sp_. Start SQL Server Profiler and connect to your server. ...

1. Range of Dates A DateTime can range from January 1, 1753 to December 31, 9999. A SmallDateTime can range from January 1, 1900 to June 6, 2079. 2. Accuracy DateTime is accurate to three-hundredths of a second. SmallDateTime is accurate to one minute. 3. Size DateTime takes up 8 bytes of storage space. SmallDateTime takes up 4 bytes of storage space. Armed with this knowledge, you may want to use SmallDateTime instead of DateTime if you only need to represent dates from January 1, 1900 to June 6, 2079 and you do not need accuracy below 1 minute. Why? Simple! Using SmallDateTime will reduce the amount of data your queries are pulling back. The size of each row will be a bit smaller.

TIP: Performance Tuning Since the COUNT function will return the same results regardless of what NOT NULL field(s) you include as the COUNT function parameters (ie: within the brackets), you can change the syntax of the COUNT function to COUNT(1) to get better performance as the database engine will not have to fetch back the data fields. For example, based on the example above, the following syntax would result in better performance: SELECT department, COUNT(1) as "Number of employees" FROM employees WHERE salary > 25000 GROUP BY department; Now, the COUNT function does not need to retrieve all fields from the employees table as it had to when you used the COUNT(*) syntax. It will merely retrieve the numeric value of 1 for each record that meets your criteria.