This is one reason to use Stored Procedures. It's easy to use a tool (be it a commercial tool or one you've created yourself, which is what we do), to keep your SP's and your .xsd's in sync. That said, you could easily do the same with the SQL string you're using, so I guess you don't really need to use an SP ... you just need a tool to generate stuff for you, and it's really not a difficult task to create your own tool.

One more thing ... if your SQL SELECT ends up returning columns that are not in your .xsd, it's ok. Those columns, with the data, will exist in your newly filled DataSet, they just won't be strongly typed. You probably don't want that to happen that way normally, but it doesn't hurt if you forget and do this once in awhile. <g>

~~Bonnie




>Ok, so I saw in another post that you RECOMMEND using Typed Datasets, but not to use the TableAdapters that it creates, but rather creating your own DataAdapters to fill the typed "tables" in the Typed DataSet, right?
>
>So, one thing that bugs me, and I just don't get it... let me try to explain:
>
>Suppose I have my Typed DataSet defind in the xsd file, and now I'm ready to create a DataAdapter in code, against that schema...(By the way, I am using OleDb to access free-standing .dbf files in a folder... No SQL server stored procedures to call here, just plain old raw tables, ready for action.)
>
>From my studies so far, here is how I see the DataAdapter used in conjunction with a Typed DataSet. Tell me if I am wrong. (Then I have my big complaint / question at the end.)
>
>

>
>public DataTable GetJobsByCustomer(string CustNo)
>{
>    OleDbConnection conn1 = new OleDbConnection(dbConnectionString);
>    conn1.Open();
>
>    LMVFP ds1 = new LMVFP(); //My Typed DataSet
>
>    string sqlstring = @"SELECT act_compda, contact, cust_num, est_cost, invoiced, job_hours,
>                        job_invnum, job_num, job_remark, job_start, mach_cost, mat_cost, mat_mkup,
>                        p_o_num, priority, quote_no, quoted_by, ship_date, ship_info, shop_notes, status, total_cost
>                        FROM job_info
>                        WHERE (cust_num = ?) AND (status = 'A')
>                        ORDER BY priority";
>    
>    OleDbDataAdapter JobsAdapter = new OleDbDataAdapter(sqlstring,conn1);
>    JobsAdapter.SelectCommand.Parameters.Add("?", OleDbType.VarChar,6).Value=CustNo;
>
>    JobsAdapter.Fill(ds1, "Jobs"); // A table schema in the Typed DataSet
>
>    return ds1.Jobs;
>
>}
>
>

>
>Is that how it goes? It does work, so that's good. And indeed the strongly typed behavior is great.
>
>Now, my gripe.... You mean to tell me that I've got maintain the same exaxt SQL syntax in my DAL method (GetJobsByCustomer) to match the schema of the table in the xsd? It's crazy to have so much maintenance and dis-join between my hand-coded SQL and the xsd schema. There's no error cathing at all, since you are writing a text string!! You get to find out at run time if it will work.
>
>When your typing all the SQL in code, it's terrible to have to look back and forth to keep your coded SQL in synch with the xsd table schema.
>
>Surely I am missing something.
>
>What a farse. The typed dataset works with beatiful intellisense and all, becuase it's generated frmo the schema, but when it comes down to it, it's just a pain to may to write SQL that matches that schema. All you've done is move the headache to a new area.
>
>Please tell me I am missing sometehing here that will make this much better.
>
>
>
>
>
>
>>My 2 cents is don't use TableAdapters. They are, more or less, a dumbed-down wrapper around the DataAdapter, IMHO.
>>
>>The designer automatically sticks them in the DataSet class and in the .xsd. So also IMHO, a DataSet should not know anything about where it gets its data, and this TableAdapter stuff totally tightly couples a DataSet with the backend DataSet. Bad, Bad, Bad. Sorry. =0(
>>
>>~~Bonnie
>>
>>
>>
>>>(VS2008) I'm trying to configure a TableAdapter in a Typed DataSet to return only a certain subset of columns from the main schema of the table on which it is based, but it always returns the entire schema (all columns) with blank values in the columns I have omitted.
>>>
>>>The TableAdpater has the default Fill and GetData() methods that come from the wizard, which contain every column in the table, which is fine. I then added a new parameterized query method called GetActiveJobsByCustNo(CustNo), and I only included a few columns in the SQL query that I actually want to be in this table view.
>>>
>>>But, again, it returns all the columns in the master table schema, with empty values for the columns I omitted.
>>>
>>>The reason I am wanting this, is so I can just get a few columns back to use that table view with AutoGenerateColumns in an ASP.NET GridView. With it giving me back EVERY column i nthe schema, my presentation GridView contains way more columns that I want to show th user. And, I want to avoid have to declare the columns in the GridView.