Showing posts with label separate. Show all posts
Showing posts with label separate. Show all posts

Thursday, March 22, 2012

Calculated field crashes VS

I had a separate post where I was having trouble displaying the entire record in the group header that was that had the max value for the details. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=641646&SiteID=1

With some help, I used a nested table in the group header, which worked perfectly except when I export the report to Excel (end user requirement) those values are replaced with ''Data Regions within table/matrix cells are ignored.''

For a workaround, I tried adding the following expression to a text box in the detail row of the table.

=iif(Fields!MAX.Value = max(Fields!MAX.Value), Fields!ASA.Value * 100, Fields!ASA.Value)

This will check the max value against the max for the group. If the max value is truely the max, it will multiple the field I am trying to display in the group header by 100. I figured I could then do a max( ) on that field in my group header, but I had no way to reference it. So...I created a calculated field with the same formula - only problem is now VS crashes until I remove the calculate field.

Any ideas why? Or if there is a way to handle this?

It is a known problem that using aggregate functions in calculated field crashes VS. We are considering fixing it in a future release. However, this scenario is not allowed. You'd get an error message when the bug is fixed.|||Thank you! Any other ideas on how I can accomplish the desired results?

Friday, February 24, 2012

C# Master-Details (Separate Pages)

My question is setting up master detail pages using stored procedrues. In the tutorials C# Master-Details (Seperate Pages) example they use the following code for the master page for the navigation.

<asp:HyperLinkField HeaderText="View Details..." Text="View Details..." DataNavigateUrlFields="au_id"
DataNavigateUrlFormatString="DetailsView_cs.aspx?ID={0}" />

The call to the Details PageDetailsView_cs.aspxuses the following code

<asp:SqlDataSource ID="SqlDataSource1" Runat="server" SelectCommand="SELECT dbo.authors.au_id, dbo.titles.title_id, dbo.titles.title, dbo.titles.type, dbo.titles.price, dbo.titles.notes FROM dbo.authors INNER JOIN dbo.titleauthor ON dbo.authors.au_id = dbo.titleauthor.au_id INNER JOIN dbo.titles ON dbo.titleauthor.title_id = dbo.titles.title_id WHERE (dbo.authors.au_id = @.au_id)"
ConnectionString="<%$ ConnectionStrings:Pubs %>">

<SelectParameters>
<asp:QueryStringParameter Name="au_id" DefaultValue="213-46-8915" QueryStringField="ID"/>
</SelectParameters>
</asp:SqlDataSource>

I can replicate the example calling the detail page but I am unable to make the detail page work when using a stored procedure as the asp:SQLDataSource. Using the above sql code as a stored procedure in the <SelectParameters> I am not able to return the data set using either asp:QueryStringParameter or asp:Parameter as I have built other forms using stored procedures and have tested the procedure and know that it works. Can someone point me in the right direction.

Thanks

The soulution works the same with stored procedures but you need to have

EnableSortingAndPagingCallbacks="false" not true

|||I spoke to soon, my previous post did not resole the issue of calling a stored procedure from the detail page. The master page passes the correct value to the detail but the procedure does not recognize it.

Thursday, February 16, 2012

buying a new server to put SQL2000 onto

Our SQL Developer asked for a new server with a separate small hard disk for the Transaction Log alone to reside on, to increase performance. This will be hard to do, since the servers we have been looking at are low-profile rackmount, and only hold 2 SATA disks. I hate to waste our only expansion bay on a small HD. Is this really something important, or will a Quad-core processor and plenty of RAM make the performance difference negligible? We have 32-bit SQL2000 licensed per processor, and our database is only about 26GB. I was hoping to get 1 large disk and partition it into a 20GB OS partition, and the rest would be for SQL. Am I totally on the wrong track?

My 2nd question is about RAM - if we get 4GB of RAM, will it decrease the performance if we get 64-bit O/S pre-installed instead of 32-bit? I know 64-bit O/S *can use* more RAM than 4GB, but does it *need* more RAM for the same level of performance that we have now? (We are planning to expand that to at least 8-12GB whenever we upgrade to 64-bit SQL2005, but the budget does not allow it just yet.)

Thanks!


Ideally, there would be separate disk arrays for the Transaction Log, the database file, and the TempDb database. Notice, I mentioned disk arrays (Or LUNs on a SAN or NAS). Now that is for a high performance, high activity enterprise critical system. You needs may not be so critical.


You didn't mention if this server was for Development work, or for Production. (Development work can get by with considerably less server capability.)


I would choose the 64bit OS, it will use memory more efficiently and will allow for easier upgrade of your SQL Server. I would 'fast track' the SQL Server upgrade to 64 bit, and additional memory. And then a SAN or NAS, or disk array.


So for now, you 'may' be able to 'live' with the two SATA disks -put the TLog files on one, and the TempDb and Datafiles on the other. Don't expect a lot of performance improvement if your current situation is 'disk bound' -you may get some improvement, just don't expect it and hopefully you will be pleasantly surprised.

|||

Thanks, here are a few more details if it helps. This is a production server, but its for a small business and high availability is not that critical. (We have time to restore from tape if needed.) According to our Developer, we are processor-bound right now, we're maxing out an older single 32-bit 3GHz Xeon. We are currently running everything on one disk and currently running with 3GB of RAM. And we're not hurting all that bad for SQL performance, we are rearranging our hardware to allow for an Exchange Server upgrade, and we're planning to move SQL to a new machine because we think it would benefit from it more than Exchange would.

Thanks again for your advice