<div>
And: 5000 rows sounds not that much. Depending on the actual service (does it return JSON or XML) even XML parsing in SQL Server is an option.<br />
<br />
But why do you think about efficiency? How often do you plan to import this data a day?
</div>


<div>
OK guys... great comments. &nbsp; So... here is the process.<br />
<br />
I have a Web Service that gets the data from the customer<br />
I execute against this service from a simple assembly on SQL Server that I call in a SQL Job<br />
SELECT [dbo].[ctcMember]()<br />
<br />
Generally... there are 3-7k records<br />
<br />
I am getting those records into a DataTable in my WCF and then passing to SQL in Structured format parameter which is received as a UserDefinedTable Type<br />
<br />
That Stored procedure loops through the User Defined Table with a CURSOR/Fetch<br />
Executes each data row against a &quot;Insert_Update_Individual Stored procedure.<br />
<br />
Based on what I am reading from you guys...<br />
This is fine... and if I have problems either &quot;clean up&quot; the fetch / Insert process or increase the job interval a little bit?
</div>


<div>
I think so. From what you say, the CURSOR is the weakest link. If it's possible to treat the data manipulation as a &quot;set&quot; operation (as opposed to one-by-one with the FETCH), that would certainly be better and more efficient - but whether that can be done or not also depends on the logic inside Insert_Update_Individual. Otherwise, if it's working, don't break it :)
</div>


<div>
Hey guys,<br />
&nbsp;Looks like MlandaT had most (personally) useful answer.<br />
<br />
Any problems with 350to him and 150 nod to James Burger?
</div>


<div>
We have absolutely nothing to say about how you assign the points. You are the one that can best see how each answer helps you and thus decide how the points should be assigned.
</div>


<div>
<div class="content wysiwyg-content">
I have a service that I pull in member data from a customer<br />
<br />
There are @ 20 columns and usually @ 5,000 records.<br />
<br />
Is it more efficient in the C# Service to read the data into a datatable<br />
Then... pass it all in at one time to SQL Server with Structured Data type <br />
The Stored procedure takes the paramater and parses it as a type Suer Defined Table<br />
<br />
<br />
OR...<br />
Just read one line at a time from the customer and pass it into SQL Server one record at a time?
</div>
</div>


I have a service that I pull in member data from a customer

There are @ 20 columns and usually @ 5,000 records.

Is it more efficient in the C# Service to read the data into a datatable
Then... pass it all in at one time to SQL Server with Structured Data type 
The Stored procedure takes the paramater and parses it as a type Suer Defined Table


OR...
Just read one line at a time from the customer and pass it into SQL Server one record at a time?

MS SQL Server 2008, C# and User Defined Tables

Microsoft SQL Server is a suite of relational database management system (RDBMS) products providing multi-user database access functionality.SQL Server is available in multiple versions, typically identified by release year, and versions are subdivided into editions to distinguish between product functionality. Component services include integration (SSIS), reporting (SSRS), analysis (SSAS), data quality, master data, T-SQL and performance tuning.

Microsoft SQL Server

C# is an object-oriented programming language created in conjunction with Microsoft’s .NET framework. Compilation is usually done into the Microsoft Intermediate Language (MSIL), which is then JIT-compiled to native code (and cached) during execution in the Common Language Runtime (CLR).

The .NET Framework is not specific to any one programming language; rather, it includes a library of functions that allows developers to rapidly build applications. Several supported languages include C#, VB.NET, C++ or ASP.NET.