Closed GoogleCodeExporter closed 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
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
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:
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
Original comment by azizatif
on 10 Oct 2007 at 8:47
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
@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
Original comment by azizatif
on 1 Jun 2009 at 5:43
Original comment by azizatif
on 1 Jun 2009 at 5:53
Implemented in r643.
Original comment by azizatif
on 1 Jun 2009 at 5:57
Original issue reported on code.google.com by
abdullah...@gmail.com
on 25 Jul 2007 at 2:31