search

parush / elmah

Automatically exported from code.google.com/p/elmah
0 stars 0 forks source link

Update SQL script for SQL Server 2005, removing obsoleted types #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
I noticed that we are using ntext data type for the sql database, but the 
SQL Server 2005 help says,

Important:
ntext, text, and image data types will be removed in a future version of 
Microsoft SQL Server. Avoid using these data types in new development 
work, and plan to modify applications that currently use them. Use nvarchar
(max), varchar(max), and varbinary(max) instead. For more information, see 
Using Large-Value Data Types.

We might want to change it to be forwards compatible

Original issue reported on code.google.com by abdullah...@gmail.com on 25 Jul 2007 at 2:31

GoogleCodeExporter commented 9 years ago 
I believe this should be an enhancement not a defect.. My mistake

Original comment by abdullah...@gmail.com on 25 Jul 2007 at 2:33

GoogleCodeExporter commented 9 years ago 
Changing the type of this issue to enhancement since the SQL script included 
right 
now is technically designed for SQL 2000 (although perhaps this should be 
mentioned 
more prominently somewhere, perhaps even as a comment within the script). 
Supporting 
SQL Server 2005 would therefore qualify as a new feature. :)

Original comment by azizatif on 25 Jul 2007 at 2:36

GoogleCodeExporter commented 9 years ago 
I have updated SQLErrorLog to create it as nvarchar(max), which according to a 
bit 
of research I did, should be safe, because it allows search functions to be 
executed 
on it, whereas ntext doesnt, and also the size is huge (2GB or so), so thats 
not a 
problem.

in the second file i removed the reference to the size of the varchar field in 
the 
parameter

Original comment by abdullah...@gmail.com on 30 Jul 2007 at 2:15

Attachments:

GoogleCodeExporter commented 9 years ago 
I tried to integrate the attached changes but it looks like this is impacting 
the 
project a lot more than expected. It could de-stabilize the route to finalizing 
version 1.0, which is where the project is right now. For example, the 
SqlErrorLog.cs provided did not take into account that the project needs to 
maintain 
compatibility with SQL Server 2000 as well as .NET Framework 1.x (at least for 
version 1.0). To make SqlErrorLog work over either SQL Server 2000 or 2005, I 
had to 
adjust the code to query the database product version and use the corresponding 
command signatures. In terms of actual difference, there's only one and that's 
the 
change in the data type of the @AllXml parameter of the ELMAH_LogError stored 
procedure. The database product version check is not a perfect solution as it 
does 
not tell you which script was really used to create the database since the SQL 
2000 
script can work on 2005 as well. I think the change in the data type of one 
table 
column and one procedure parameter seems too small a benefit for the impact it 
has 
on the code and back-end versioning approach at this point (it warrants more 
design 
and review). It would have been a lot more worth the effort if, for example, 
the 
script for SQL 2005 was truly taking advantage of a lot more sophisticated 
features, 
such as XML data type and paging.

What I have done for now is created a trial branch that records the changes 
that 
were needed (as it turned out to be interesting experiment nonetheless on the 
code 
could be impacted) and which can be found here:

http://elmah.googlecode.com/svn/trials/aa/sqlserver-mix/

For version 1.0, I think we'll need to rely on the SQL 2000 script for 2005 as 
well 
and then think about dropping support for 2000 altogether when moving beoynd 
1.0. If 
not, we'll have the branch above to start picking up things from again as the 
work 
is not lost.

Original comment by azizatif on 31 Jul 2007 at 8:21

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 10 Oct 2007 at 8:47

GoogleCodeExporter commented 9 years ago 
This is important if you have a 15gb table that keeps growing and causing 
issues on a 
small DB server.

Original comment by eugenepe...@gmail.com on 20 Oct 2008 at 3:36

GoogleCodeExporter commented 9 years ago 
@eugenepevzner: Not sure what you mean. Care to expand? If you errors table is 
15GB 
big then you might want to think about hosting it in a separate database from 
your 
application.

Original comment by azizatif on 20 Oct 2008 at 3:41

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 1 Jun 2009 at 5:43

GoogleCodeExporter commented 9 years ago

Original comment by azizatif on 1 Jun 2009 at 5:53

GoogleCodeExporter commented 9 years ago 
Implemented in r643.

Original comment by azizatif on 1 Jun 2009 at 5:57