Optimal way to retrieve data from a linked server?

Question

Hi,
If I create a view for our "Support Calls" list inside our database the SQL code looks like this...
Code Snippet
SELECT CALL.REFERENCE AS CallRef,
 CALL.CUSTOMERREF AS CustomerRef,
 CUSTOMER.NAME,
 DATEADD(hh,CALL.OPENHRS, DATEADD(n, CALL.OPENMINS, CALL.OPENDATE)) AS Opened,
 DATEADD(hh, CALL.CLOSEHRS, DATEADD(n, CALL.CLOSEMINS, CALL.CLOSEDATE)) AS Closed,
 DATEADD(hh, CALL.ACTHRS, DATEADD(n, CALL.ACTMINS, CALL.ACTDATE)) AS Actioned,
 CALL.PRODUCTREF,
 SUPPROD.NAME AS ProductName,
 CODES_2.CATEGORY AS CallType,
 REPLACE(CODES_3.CATEGORY, '£ ', '') AS CallStatus,
 CODES_4.CATEGORY AS CallPriority,
 CALL.TITLE,
        CALL.CALLER,
 CALL.HANDLERTAG,
 CODES_1.CATEGORY AS SLA,
        CODES.CATEGORY AS ActionCategory,
 CALL.szemail,
 CALL.szphone,
 CALL.szline,
        CALL.szresolvedby
FROM    EVENT
INNER JOIN
 CODES ON CALL.ACT = CODES.NO INNER JOIN
        CODES AS CODES_1 ON CALL.CATAREA = CODES_1.NO INNER JOIN
        CODES AS CODES_2 ON CALL.CATTYPE = CODES_2.NO INNER JOIN
        CODES AS CODES_3 ON CALL.CATSTATUS = CODES_3.NO INNER JOIN
        CODES AS CODES_4 ON CALL.CATPRIORITY = CODES_4.NO INNER JOIN
        SUPCUST ON CALL.CUSTOMERREF = CUSTOMER.REFERENCE INNER JOIN
        SUPPROD ON CALL.PRODUCTREF = SUPPROD.REFERENCE
Support calls that are closed are simply moved from the CALL table, to a table called ARCHIVED_CALL which is identical in structure.
So, if I want a single view to present all support calls, the query string would be twice as long as the one above unless I create two views (one for each database) and use a third view to UNION them.
Thing is, I can't create the views inside the enterprise database (political reasons); I have to do it from another server.
The enterprise system is on a quad core server on the same gigabit switch as the dual core server hosting the SQL instance that is retrieving the data.
I tried creating a view based on an openquery statement e.g.
Code Snippet
SELECT * FROM OPENQUERY([ENTERPRISE SERVER],
        'SELECT ..... FROM CALL UNION ALL SELECT ..... FROM ARCHIVED_CALL')
Can't say I'm impressed. The returned dataset has under 4000 records in it, but it takes more than 15 seconds to execute the query.
This is by far the smallest dataset that we need to work with - the support call notes tables (live and archived) contain over 60,000 records in total. I can boil the kettle, make a pot of tea, leave it to brew and then pour when ready, before the view finishes doing its job!
I tried using SPs to populate a local table with the data returned by the OPENQUERY, but this turned out to be a real headache when handling situations like users updating or archiving support calls; the only way that seemed to work was by dropping all records and then reimporting them and that didn't seem to be any faster.
Any ideas?

Answer 1

Hi,
Sorry for the delay in getting back to you all. I've got a bit of expanded info for you which'll probably help you understand the situation better.
We have two databases, call 'em Support and Sales for the sake of argument, and they format data differently so I have a proof-of-concept SP which gets just the customer names and references from each table, then creates a temp table formatted as follows:
Customer ------- Support Reference - Sales Reference
ABC SITE1        ABC                 ABC1
ABC SITE2        ABC                 ABC2
ABD CUSTOMER                         ABD1     
BBB SUPPORTONLY  BBB  
So in Sharepoint, for example, someone does a customer name search and they will get a list of customers who fit the bill, along with links to the various customer records.
And the code I'm predominately concerned with, is this bit of it:
Code Snippet
create table #SupportIDs
[Customer Name] varchar(120),
[Support Reference] varchar(16)
create table #SalesIDs
[Customer Name] varchar(120),
[Sales Reference] varchar(16)
INSERT INTO #SupportIDs
    SELECT [Customer Name], [Support Reference] FROM  
    OPENQUERY([SUPPORTSERVER],        'SELECT NAME AS [Customer Name],
                                REFERENCE AS [Support Reference]
                                FROM Support.CUSTOMERS')
INSERT INTO #SalesIDs
    SELECT [Customer Name],
        [Sales Reference] FROM  
    OPENQUERY([SALESSERVER], 'SELECT name as [Customer Name], customer as [Sales Reference]
FROM         Sales.CUSTOMERLIST')
SELECT dbo.Neaten([Customer Name]),
   dbo.Neaten([Support Reference]),
   '' AS [Sales Reference]
FROM #SupportIDs
UNION ALL
SELECT dbo.Neaten([Customer Name]),
   '' AS [Support Reference],
   dbo.Neaten([Sales Reference]) FROM #SalesIDs
// dbo.Neaten performs left & right trim, strips out illegal characters, and then converts to uppercase.
It takes no time at all to drag the data into #SupportIDs (<1 second), but it takes >10 seconds to do the same with the data from #SalesIDs, purely because the Sales database is hosted on a SQL 2000 instance on an old server the other side of a slow WAN link from here.
In total, there are less than 2750 records returned from the SP in the UNION statement, 2100 of which are coming from the #SalesIDs temp table.
The function Neaten just strips out white space and capitalises the value.
If I can store this dataset in a local table, and have a trigger on the SQL instance which refreshes the table once a day, then I think we could probably live with it.
The ADF for BDC would only need to point to the local table if that were the case.