|
database
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Deep SQL .Net integration questionspecific table as it relates to ADO.Net or other .net functionality? My short story is that I have made a net gain in the number of columns on a table and I am getting errors when I create new update sprocs for that table. The error is that too many parameters are being specified (more on that later). I have created new sprocs with different names, fewer parameters, deleted old ones etc with no luck on this table. The new sprocs work fine when running them from sql and they run fine when writing .Net code with an application. So where does the error happen? When using SqlDataSource controller is Asp.net. I re-created the problem on a separate machine from scratch with a new application. I tested other sprocs that access other tables with nearly exactly the same set up and I get no errors. So I am nearly positive that SQL itself is holding some reference to the old sproc in someway that SqlDataSource controller. I am nearly positive that if I convert everything to ObjectDataSource controller I would not have this problem. If that is true it will answer the question I have had for a long time which is why use the objectdatasource controller if you don’t have to. Answer? Because SqlDatasource controller is very unreliable. This is a complex issue so I will be more then happy to provide as much information as possible. I am interested in solving the problem because I think it will give me a better understanding of how SQL 2005 works with .Net Sean (S***@discussions.microsoft.com) writes:
Show quote > Is it possible for SQL 2005 to be holding an old sproc signature to a It could help if you could be more specific and include source, tables> specific table as it relates to ADO.Net or other .net functionality? > > My short story is that I have made a net gain in the number of columns > on a table and I am getting errors when I create new update sprocs for > that table. The error is that too many parameters are being specified > (more on that later). I have created new sprocs with different names, > fewer parameters, deleted old ones etc with no luck on this table. > > The new sprocs work fine when running them from sql and they run fine when > writing .Net code with an application. So where does the error happen? > When using SqlDataSource controller is Asp.net. > > I re-created the problem on a separate machine from scratch with a new > application. I tested other sprocs that access other tables with nearly > exactly the same set up and I get no errors. > > So I am nearly positive that SQL itself is holding some reference to the > old sproc in someway that SqlDataSource controller. > > I am nearly positive that if I convert everything to ObjectDataSource > controller I would not have this problem. If that is true it will answer > the question I have had for a long time which is why use the > objectdatasource controller if you don’t have to. Answer? Because > SqlDatasource controller is very unreliable. and not the least error messages. You drop some columns from a table, and you get errors about too many parameters? That sounds funky to me. Then again, I have very little idea of what you are doing. You mention something called SqlDataSource. This is something completely unknown to me. So whatever, I don't think that SQL Server itself holds any references to stored procedure in this SqlDataSource. Or to be more blunt: I know it doesn't, because in that case I would have known what SqlDataSource is. But maybe SqlDataSource is a component in ASP .Net and it happens to holds stale information. ASP .Net I know about zero of. -- Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx More then likley if you dont know what sqlDataSource is or have deep knowedge
of sql 2005 specifically then you are not going to be able to help me. The error is specific to that control. The reason I know its not stale information in the control itself is becuase I have created 2 virgin applications on 2 different machines using this control which only gives me an error for update sprocs on this specific table which is from my experience literally impossible but that is exactly what it is doing. Show quote "Erland Sommarskog" wrote: > Sean (S***@discussions.microsoft.com) writes: > > Is it possible for SQL 2005 to be holding an old sproc signature to a > > specific table as it relates to ADO.Net or other .net functionality? > > > > My short story is that I have made a net gain in the number of columns > > on a table and I am getting errors when I create new update sprocs for > > that table. The error is that too many parameters are being specified > > (more on that later). I have created new sprocs with different names, > > fewer parameters, deleted old ones etc with no luck on this table. > > > > The new sprocs work fine when running them from sql and they run fine when > > writing .Net code with an application. So where does the error happen? > > When using SqlDataSource controller is Asp.net. > > > > I re-created the problem on a separate machine from scratch with a new > > application. I tested other sprocs that access other tables with nearly > > exactly the same set up and I get no errors. > > > > So I am nearly positive that SQL itself is holding some reference to the > > old sproc in someway that SqlDataSource controller. > > > > I am nearly positive that if I convert everything to ObjectDataSource > > controller I would not have this problem. If that is true it will answer > > the question I have had for a long time which is why use the > > objectdatasource controller if you don’t have to. Answer? Because > > SqlDatasource controller is very unreliable. > > It could help if you could be more specific and include source, tables > and not the least error messages. You drop some columns from a table, and > you get errors about too many parameters? That sounds funky to me. Then > again, I have very little idea of what you are doing. > > You mention something called SqlDataSource. This is something completely > unknown to me. So whatever, I don't think that SQL Server itself holds > any references to stored procedure in this SqlDataSource. Or to be more > blunt: I know it doesn't, because in that case I would have known what > SqlDataSource is. > > But maybe SqlDataSource is a component in ASP .Net and it happens to > holds stale information. ASP .Net I know about zero of. > > -- > Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se > > Books Online for SQL Server 2005 at > http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx > Books Online for SQL Server 2000 at > http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx > Sean (S***@discussions.microsoft.com) writes:
> More then likley if you dont know what sqlDataSource is or have deep Most of all, I am not able to help you if you don't tell us what you> knowedge of sql 2005 specifically then you are not going to be able to > help me. The error is specific to that control. are doing. If the error is specific to the SqlDataSource control, then you should ask in a forum where people have knowledge about this control (an ASP .Net forum I guess). In this newsgroup we can offer expertise on SQL Server (including SQL 2005), but without knowledge of what you did vis-à-vis SQL Server, it is difficult to answer. > The reason I know its not stale information in the control itself is Well, one possible explanation is that there are two tables with the same> becuase I have created 2 virgin applications on 2 different machines > using this control which only gives me an error for update sprocs on > this specific table which is from my experience literally impossible but > that is exactly what it is doing. name, one in the DBO schema and one which is the default schema when you connect from SqlDataSource. One way to check this is to run: SELECT schema_name(schema_id), * FROM sys.objects WHERE name = 'yourtable' Of course, this is just a shot in the dark. It would certainly help if you included more information of what you actually did, including the code of the stored procedures you try to create and the error message. Some overview of what SqlDataSource helps too. -- Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx Are you at all familar with the schema generated by Sql 2005 service broker?
Show quote "Erland Sommarskog" wrote: > Sean (S***@discussions.microsoft.com) writes: > > More then likley if you dont know what sqlDataSource is or have deep > > knowedge of sql 2005 specifically then you are not going to be able to > > help me. The error is specific to that control. > > Most of all, I am not able to help you if you don't tell us what you > are doing. > > If the error is specific to the SqlDataSource control, then you should ask > in a forum where people have knowledge about this control (an ASP .Net forum > I guess). In this newsgroup we can offer expertise on SQL Server (including > SQL 2005), but without knowledge of what you did vis-Ã -vis SQL Server, > it is difficult to answer. > > > The reason I know its not stale information in the control itself is > > becuase I have created 2 virgin applications on 2 different machines > > using this control which only gives me an error for update sprocs on > > this specific table which is from my experience literally impossible but > > that is exactly what it is doing. > > Well, one possible explanation is that there are two tables with the same > name, one in the DBO schema and one which is the default schema when you > connect from SqlDataSource. One way to check this is to run: > > SELECT schema_name(schema_id), * > FROM sys.objects > WHERE name = 'yourtable' > > Of course, this is just a shot in the dark. It would certainly help if > you included more information of what you actually did, including the > code of the stored procedures you try to create and the error message. > Some overview of what SqlDataSource helps too. > > > -- > Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se > > Books Online for SQL Server 2005 at > http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx > Books Online for SQL Server 2000 at > http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx > Sean (S***@discussions.microsoft.com) writes:
> Are you at all familar with the schema generated by Sql 2005 service Service Broker?> broker? So there the moral goes again. When you post a question, always be as clear of what you are doing as possible. Had you said you are using Service Broker, I would not have embarrassed myself in public, since that is a component of SQL Server I have yet to learn. All I could read out from your post that you had changed a table, and then where was something wrong with procedures in some SqlDataSource and that SQL Server would hold any information there. Well, I don't know much about Service Broker, but I'm fairly certain that it holds its information within the database. By the way, you have still not posted the error message, or showed us the code you are trying to use. But maybe you only post to vent your frustration, and not really seeking assistence, who knows... -- Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se Books Online for SQL Server 2005 at http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx Books Online for SQL Server 2000 at http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx It looks like the answer to my question is as follows.
when running as provider system.data.sqlclient the the service broker in SQL 2005 manages messages and Queues. It apears that I have an error in my SQL 2005 Service Broker Queue that is basically stuck. The DBA from my web hosting provider is going to get back to me about how I can clear this queue. Yes, this is a SQL 2005 database issue and its specific only to Sql 2005 new features which I do not explicititly implement. Look, binding to a datagrid is insanely simple Its hard to work with one datagrid and one sqldatasource controller for 10 hours and not get it right. I feel 1000% confident that I got the developement side take care of correctly. Not to mention I replicated the exact same problem on different machines using virgin applications using nothing more then a one datagrid and a datasource controller. I could spend another 10 hours documenting every move a made but I was basically asking if SQL 2005 can hold a reference to legacy information and the correct answer is yes it can. Show quote "Erland Sommarskog" wrote: > Sean (S***@discussions.microsoft.com) writes: > > Are you at all familar with the schema generated by Sql 2005 service > > broker? > > Service Broker? > > So there the moral goes again. When you post a question, always be as clear > of what you are doing as possible. Had you said you are using Service > Broker, I would not have embarrassed myself in public, since that is a > component of SQL Server I have yet to learn. > > All I could read out from your post that you had changed a table, and > then where was something wrong with procedures in some SqlDataSource > and that SQL Server would hold any information there. Well, I don't > know much about Service Broker, but I'm fairly certain that it holds > its information within the database. > > By the way, you have still not posted the error message, or showed us the > code you are trying to use. > > But maybe you only post to vent your frustration, and not really seeking > assistence, who knows... > -- > Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se > > Books Online for SQL Server 2005 at > http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx > Books Online for SQL Server 2000 at > http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx > First thanks for being patient with my abstract information and I did try
the sys.objects after reading that with no luck. I finally was able to debug enough to find some useful information so that I can actually start asking questions less abstractly. The SQL 2005 server that I am accessing remotely is sending me one extra parameter for that stored procedure. I now know the exact name of it and was able to confirm that it’s not in the stored procedure. Your all right that this might end up as a developer question however I am almost positive the problem lies in system.data.sqlclient running on this Sql 2005 remote server. Why do I think it’s not on my development app? Because I created a new application on a separate machine that contains nothing more than a grid and the data controller. Such an application literally has zero lines of code about a page of markup. Anyway sorry I was not able to get more information until now and I am not sure it helps. I think I need an expert in the system.data.sqlclient namespace and you might be right that it leads me to a developer forum. Show quote "Erland Sommarskog" wrote: > Sean (S***@discussions.microsoft.com) writes: > > More then likley if you dont know what sqlDataSource is or have deep > > knowedge of sql 2005 specifically then you are not going to be able to > > help me. The error is specific to that control. > > Most of all, I am not able to help you if you don't tell us what you > are doing. > > If the error is specific to the SqlDataSource control, then you should ask > in a forum where people have knowledge about this control (an ASP .Net forum > I guess). In this newsgroup we can offer expertise on SQL Server (including > SQL 2005), but without knowledge of what you did vis-à -vis SQL Server, > it is difficult to answer. > > > The reason I know its not stale information in the control itself is > > becuase I have created 2 virgin applications on 2 different machines > > using this control which only gives me an error for update sprocs on > > this specific table which is from my experience literally impossible but > > that is exactly what it is doing. > > Well, one possible explanation is that there are two tables with the same > name, one in the DBO schema and one which is the default schema when you > connect from SqlDataSource. One way to check this is to run: > > SELECT schema_name(schema_id), * > FROM sys.objects > WHERE name = 'yourtable' > > Of course, this is just a shot in the dark. It would certainly help if > you included more information of what you actually did, including the > code of the stored procedures you try to create and the error message. > Some overview of what SqlDataSource helps too. > > > -- > Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se > > Books Online for SQL Server 2005 at > http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx > Books Online for SQL Server 2000 at > http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx > Actually, many of us would strongly disagree. Erland definitely demonstrates
'deep knowledge' of SQL Server. Since the SQLDataSource object is specific to Visual Studio.NET and not internal to SQL Server, I wouldn't expect SQL experts to have more than a passing awareness of it -even if that. However, it seems to be that you would be better served seeking help in a VS.NET newsgroup where you can obtain assistance from those that may be more aware of a SQLDataSource object. You may wish to review the datagrid bindings to determine if there is a problem in how the application is attempting to use the SQLDataSource object. -- Show quoteArnie Rowland, Ph.D. Westwood Consulting, Inc Most good judgment comes from experience. Most experience comes from bad judgment. - Anonymous "Sean" <S***@discussions.microsoft.com> wrote in message news:DF1EC92B-2904-4F2F-93C7-7E7D8FDBAFEC@microsoft.com... > More then likley if you dont know what sqlDataSource is or have deep > knowedge > of sql 2005 specifically then you are not going to be able to help me. > The error is specific to that control. > > The reason I know its not stale information in the control itself is > becuase > I have created 2 virgin applications on 2 different machines using this > control which only gives me an error for update sprocs on this specific > table > which is from my experience literally impossible but that is exactly what > it > is doing. > > "Erland Sommarskog" wrote: > >> Sean (S***@discussions.microsoft.com) writes: >> > Is it possible for SQL 2005 to be holding an old sproc signature to a >> > specific table as it relates to ADO.Net or other .net functionality? >> > >> > My short story is that I have made a net gain in the number of columns >> > on a table and I am getting errors when I create new update sprocs for >> > that table. The error is that too many parameters are being specified >> > (more on that later). I have created new sprocs with different names, >> > fewer parameters, deleted old ones etc with no luck on this table. >> > >> > The new sprocs work fine when running them from sql and they run fine >> > when >> > writing .Net code with an application. So where does the error happen? >> > When using SqlDataSource controller is Asp.net. >> > >> > I re-created the problem on a separate machine from scratch with a new >> > application. I tested other sprocs that access other tables with nearly >> > exactly the same set up and I get no errors. >> > >> > So I am nearly positive that SQL itself is holding some reference to >> > the >> > old sproc in someway that SqlDataSource controller. >> > >> > I am nearly positive that if I convert everything to ObjectDataSource >> > controller I would not have this problem. If that is true it will >> > answer >> > the question I have had for a long time which is why use the >> > objectdatasource controller if you don't have to. Answer? Because >> > SqlDatasource controller is very unreliable. >> >> It could help if you could be more specific and include source, tables >> and not the least error messages. You drop some columns from a table, and >> you get errors about too many parameters? That sounds funky to me. Then >> again, I have very little idea of what you are doing. >> >> You mention something called SqlDataSource. This is something completely >> unknown to me. So whatever, I don't think that SQL Server itself holds >> any references to stored procedure in this SqlDataSource. Or to be more >> blunt: I know it doesn't, because in that case I would have known what >> SqlDataSource is. >> >> But maybe SqlDataSource is a component in ASP .Net and it happens to >> holds stale information. ASP .Net I know about zero of. >> >> -- >> Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se >> >> Books Online for SQL Server 2005 at >> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx >> Books Online for SQL Server 2000 at >> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx >> Thanks, I think its related to Service Broker and conversations as it relates
to this control. That is what I am looking into this afternoon I think there is a conversation pointing to this typ of control that never closed. Show quote "Arnie Rowland" wrote: > Actually, many of us would strongly disagree. Erland definitely demonstrates > 'deep knowledge' of SQL Server. > > Since the SQLDataSource object is specific to Visual Studio.NET and not > internal to SQL Server, I wouldn't expect SQL experts to have more than a > passing awareness of it -even if that. However, it seems to be that you > would be better served seeking help in a VS.NET newsgroup where you can > obtain assistance from those that may be more aware of a SQLDataSource > object. > > You may wish to review the datagrid bindings to determine if there is a > problem in how the application is attempting to use the SQLDataSource > object. > > -- > Arnie Rowland, Ph.D. > Westwood Consulting, Inc > > Most good judgment comes from experience. > Most experience comes from bad judgment. > - Anonymous > > > "Sean" <S***@discussions.microsoft.com> wrote in message > news:DF1EC92B-2904-4F2F-93C7-7E7D8FDBAFEC@microsoft.com... > > More then likley if you dont know what sqlDataSource is or have deep > > knowedge > > of sql 2005 specifically then you are not going to be able to help me. > > The error is specific to that control. > > > > The reason I know its not stale information in the control itself is > > becuase > > I have created 2 virgin applications on 2 different machines using this > > control which only gives me an error for update sprocs on this specific > > table > > which is from my experience literally impossible but that is exactly what > > it > > is doing. > > > > "Erland Sommarskog" wrote: > > > >> Sean (S***@discussions.microsoft.com) writes: > >> > Is it possible for SQL 2005 to be holding an old sproc signature to a > >> > specific table as it relates to ADO.Net or other .net functionality? > >> > > >> > My short story is that I have made a net gain in the number of columns > >> > on a table and I am getting errors when I create new update sprocs for > >> > that table. The error is that too many parameters are being specified > >> > (more on that later). I have created new sprocs with different names, > >> > fewer parameters, deleted old ones etc with no luck on this table. > >> > > >> > The new sprocs work fine when running them from sql and they run fine > >> > when > >> > writing .Net code with an application. So where does the error happen? > >> > When using SqlDataSource controller is Asp.net. > >> > > >> > I re-created the problem on a separate machine from scratch with a new > >> > application. I tested other sprocs that access other tables with nearly > >> > exactly the same set up and I get no errors. > >> > > >> > So I am nearly positive that SQL itself is holding some reference to > >> > the > >> > old sproc in someway that SqlDataSource controller. > >> > > >> > I am nearly positive that if I convert everything to ObjectDataSource > >> > controller I would not have this problem. If that is true it will > >> > answer > >> > the question I have had for a long time which is why use the > >> > objectdatasource controller if you don't have to. Answer? Because > >> > SqlDatasource controller is very unreliable. > >> > >> It could help if you could be more specific and include source, tables > >> and not the least error messages. You drop some columns from a table, and > >> you get errors about too many parameters? That sounds funky to me. Then > >> again, I have very little idea of what you are doing. > >> > >> You mention something called SqlDataSource. This is something completely > >> unknown to me. So whatever, I don't think that SQL Server itself holds > >> any references to stored procedure in this SqlDataSource. Or to be more > >> blunt: I know it doesn't, because in that case I would have known what > >> SqlDataSource is. > >> > >> But maybe SqlDataSource is a component in ASP .Net and it happens to > >> holds stale information. ASP .Net I know about zero of. > >> > >> -- > >> Erland Sommarskog, SQL Server MVP, esq***@sommarskog.se > >> > >> Books Online for SQL Server 2005 at > >> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx > >> Books Online for SQL Server 2000 at > >> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx > >> > > > > The error is that too many parameters are being specified From the VS 2005 Documentation:<Excerpt href="ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_aspnetcon/html/403ff44a-dd0b-484d-968e-dcd1dcd4c295.htm"> The SqlDataSource control will also automatically create parameters based on values passed by a data-bound control (such as a GridView or FormView control) that supports automatic update, insert, and delete operations. For more information, see How a Data Source Control Creates Parameters for Data-bound Fields. </Excerpt> Consequently, it might be that you have a data-bound control without corresponding procedure parameters, resulting in the too many parameters error. -- Show quoteHope this helps. Dan Guzman SQL Server MVP "Sean" <S***@discussions.microsoft.com> wrote in message news:B7B41D04-6F23-4725-9CA4-E637D5C743B2@microsoft.com... > Is it possible for SQL 2005 to be holding an old sproc signature to a > specific table as it relates to ADO.Net or other .net functionality? > > My short story is that I have made a net gain in the number of columns on > a > table and I am getting errors when I create new update sprocs for that > table. > The error is that too many parameters are being specified (more on that > later). I have created new sprocs with different names, fewer parameters, > deleted old ones etc with no luck on this table. > > The new sprocs work fine when running them from sql and they run fine when > writing .Net code with an application. So where does the error happen? > When using SqlDataSource controller is Asp.net. > > I re-created the problem on a separate machine from scratch with a new > application. I tested other sprocs that access other tables with nearly > exactly the same set up and I get no errors. > > So I am nearly positive that SQL itself is holding some reference to the > old > sproc in someway that SqlDataSource controller. > > I am nearly positive that if I convert everything to ObjectDataSource > controller I would not have this problem. If that is true it will answer > the > question I have had for a long time which is why use the objectdatasource > controller if you don't have to. Answer? Because SqlDatasource controller > is > very unreliable. > > This is a complex issue so I will be more then happy to provide as much > information as possible. I am interested in solving the problem because I > think it will give me a better understanding of how SQL 2005 works with > .Net > I have moved my investigation to the notification services becuase I noticed
that service brokers hold schemas. So I did some looking and it apears that if conversations are not closed that referenences to them can still exist. I am looking into if the SQLDataSource control doesnt take a sproc then create a service broker conversation. Spending 10 hours on the application side for a very simple grid with 11 columns, 1 primary key, no foreign keys while at the same time having an almost identical table with nearly the identical structure not producing errors gives me confidence that I got the possible errors from the developer take care of...;) Sean mcad Show quote "Dan Guzman" wrote: > > The error is that too many parameters are being specified > > From the VS 2005 Documentation: > > <Excerpt > href="ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_aspnetcon/html/403ff44a-dd0b-484d-968e-dcd1dcd4c295.htm"> > > The SqlDataSource control will also automatically create parameters based on > values passed by a data-bound control (such as a GridView or FormView > control) that supports automatic update, insert, and delete operations. For > more information, see How a Data Source Control Creates Parameters for > Data-bound Fields. > > </Excerpt> > > Consequently, it might be that you have a data-bound control without > corresponding procedure parameters, resulting in the too many parameters > error. > > -- > Hope this helps. > > Dan Guzman > SQL Server MVP > > "Sean" <S***@discussions.microsoft.com> wrote in message > news:B7B41D04-6F23-4725-9CA4-E637D5C743B2@microsoft.com... > > Is it possible for SQL 2005 to be holding an old sproc signature to a > > specific table as it relates to ADO.Net or other .net functionality? > > > > My short story is that I have made a net gain in the number of columns on > > a > > table and I am getting errors when I create new update sprocs for that > > table. > > The error is that too many parameters are being specified (more on that > > later). I have created new sprocs with different names, fewer parameters, > > deleted old ones etc with no luck on this table. > > > > The new sprocs work fine when running them from sql and they run fine when > > writing .Net code with an application. So where does the error happen? > > When using SqlDataSource controller is Asp.net. > > > > I re-created the problem on a separate machine from scratch with a new > > application. I tested other sprocs that access other tables with nearly > > exactly the same set up and I get no errors. > > > > So I am nearly positive that SQL itself is holding some reference to the > > old > > sproc in someway that SqlDataSource controller. > > > > I am nearly positive that if I convert everything to ObjectDataSource > > controller I would not have this problem. If that is true it will answer > > the > > question I have had for a long time which is why use the objectdatasource > > controller if you don't have to. Answer? Because SqlDatasource controller > > is > > very unreliable. > > > > This is a complex issue so I will be more then happy to provide as much > > information as possible. I am interested in solving the problem because I > > think it will give me a better understanding of how SQL 2005 works with > > .Net > > > > >  |
|||||||||||||||||||||||
Other interesting topics