Sql Quries
Jun 11, 2007
Hi,
Anyone can send the Sql query questions i need to pratice quries on sqlserver.
Regards,
Hari Prasad
Hi,
Anyone can send the Sql query questions i need to pratice quries on sqlserver.
Regards,
Hari Prasad
Hi Friends
I want Some Power Point Presentations In MS SQL SERVER 2000
1. Joins
2. Views
3. Basic Queries
4. Functions
5. Store Procedures and Cursors
All the above i want PPTs could you any body please send me
Can anyone know the difference between using distributed queries for transfering data and replication.
Which is more reliable and which is the better way?
If the volume of database over 2,000,000 with nearly 100 columns,which is the better method?
I have Two Access Databases connected as Linked servers through ODBC driver.
I want to run a Distributed Query .
The SQL is as follows:
SELECT Alias1.FiledNames,Alias2.FiledNames from
FROM LinkedServer1.DatabaseName1.dbo.Tablename1 AS Alias1,
LinkedServer2.DatabaseName2.dbo.Tablename2 AS Alias2
It gives me this error message.
ODBC: Msg 0, Level 19, State 1
SqlDumpExceptionHandler: Process 12 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.
Connection Broken
Am i missing something?
Thanks in Adavance
Puru
Here are the tables I am dealing with:
Tables
license TABLE
---------------
license_id int PK
vendor_id int FK
po_id int FK Nulls
license_type_id int FK
lic_user_id int FK Nulls
location_id int FK Nulls
lic_start_date smalldatetime Nulls
days_allowed int Nulls
serial_num varchar(50) Nulls
activation_key varchar(50) Nulls
max_users int Nulls
comments varchar(1000) Nulls
software TABLE
------------------
software_id int PK
os_id int
software_name varchar(150)
comments varchar(1000) Nulls
software_license TABLE
--------------------------
license_id int PK , FK
software_id int PK , FK
comments varchar(1000) Nulls
dept_license TABLE
---------------------
dept_id int PK , FK
license_id int PK , FK
comments varchar(1000) Nulls
purch_order TABLE
---------------------
po_id int PK
po_number varchar(50)
po_date smalldatetime
comments varchar(1000) Nulls
dept_purch_order TABLE
----------------------------
po_id int PK , FK
dept_id int PK , FK
comments varchar(1000) Nulls
I am using the following stored proceedure to try to create a useful report from those tables:
Code Block
ALTER PROCEDURE [dbo].[ListDepartmentLicenses]
@Department int,
@Software int
AS
BEGIN
SET NOCOUNT ON;
SELECT dept_license.license_id,
license.lic_start_date,
department.dept_name,
purch_order.po_number,
software.software_name
FROM dept_license
JOIN license
ON dept_license.license_id = license.license_id
JOIN department
ON dept_license.dept_id = department.dept_id
JOIN dept_purch_order
ON dept_purch_order.dept_id = dept_license.dept_id
JOIN purch_order
ON dept_purch_order.po_id = purch_order.po_id
JOIN software_license
ON dept_license.license_id = software_license.license_id
JOIN software
ON software_license.software_id = software.software_id
WHERE (department.dept_id = @Department or @Department Is Null) and
(software.software_id = @Software or @Software Is Null)
ORDER BY license.lic_start_date
END
The sproc compiles fine but I get no rows returned.
I am running simple queries against test SQL Express installation and they take a very long time to return data. I have two SQL Express instances installed on colleagues' machines to which I connect for my testing and both exhibit the same problem. The setup is Windows XP SP 2 with 2 GB RAM and 3.6 GHz CPU. I am querying a table with around 7000 records and my query is simply SELECT TOP 1000 * FROM MyTable. It takes over 10 seconds to return the recordset!
I have done the research and found posts, which talk about AUTO_CLOSE option, indexes, query execution plan, etc. I have done everything those posts recommend, but performance is still terrible. All the instances have SQL 2005 SP2 applied.
I also found that the query runs fast locally on each SQL Express instance, the problem seem to happen when I am trying to pull the data over the network.
I am really not sure what else to look for.
Thank you,
Michael