Ah - I did read that, didn't answer it though. ;-P If you do data binding with web controls, you could be "linking in" parameters from other controls. The concept I understand - but when I do AJAX I route around the dotNet Framework. See, I don't like that the dotNet tutorials I learned with taught a post back for each click and select. Seemed like too much work and too much irritation to the user. MS Report Server does this with the selectable parameters on a report. Highly annoying. So I use AJAX to work any selects / form elements that need to be updated because of other form elements. Now MS has their their own AJAX Toolkit - but we are heavily invested in the Yahoo AJAX Tool set because MS didn't release theirs until January and I needed a working tool set 12 months ago. But you might want to look at MS's AJAX Solution and see how that integrates with the dotNet Web Controls and their data binding / view state / post back needs. Hope that helps. -----Original message----- From: "Joel D Canfield" joel at streamliine.com Date: Thu, 28 Jun 2007 15:25:54 -0700 To: "Anthony Baratta" anthony at baratta.com, thelist at lists.evolt.org Subject: RE: [thelist] .NET and MSSQL data validation > [reordered to put the most important on top] > > > Second, constraints and such should be a DB level function - > > not a code level issue. Use the DB first, code as a backup / > > yes, right, exactly - I didn't 'splain myself well. > > in the db, *this* data port is connected to *that* office; all proper db > constraints in place. > > now, the user goes to set up a new user's info in the db. when they > select the office New User is assigned, and then go to assign their > computer to a data port, the select should only populate with data ports > from that office. normally, I'd restrict the select options using code > (okay, probably way back in the SQL query somewhere.) > > will .NET see that connection in the SQL db and assume it for me? that > was what I really meant to ask.