When will Microsoft provide functionality that we can write functions for reporting services in c#?

Twelve years ago we had one language for asp, dhtml, office, SQL server and batch files.

How many languages do we need today to do the same thing?

Canada Getting Rid Of Pennies

Finally figured out that I had to push the error values in as constants.

SET @Query = ‘SELECT ‘ + CHAR(39) + REPLACE(CONVERT(VARCHAR(1000), ERROR_NUMBER()), CHAR(39), ”) + CHAR(39) + ‘ AS ErrorNumber
,’ + CHAR(39) + REPLACE(CONVERT(VARCHAR(1000), ERROR_SEVERITY()), CHAR(39), ”) + CHAR(39) + ‘ AS ErrorSeverity
,’ + CHAR(39) + REPLACE(CONVERT(VARCHAR(1000), ERROR_STATE()), CHAR(39), ”) + CHAR(39) + ‘ AS ErrorState
,’ + CHAR(39) + REPLACE(CONVERT(VARCHAR(1000), ERROR_PROCEDURE()), CHAR(39), ”) + CHAR(39) + ‘ AS ErrorProcedure
,’ + CHAR(39) + REPLACE(CONVERT(VARCHAR(1000), ERROR_LINE()), CHAR(39), ”) + CHAR(39) + ‘ AS ErrorLine
,’ + CHAR(39) + REPLACE(CONVERT(VARCHAR(1000), ERROR_MESSAGE()), CHAR(39), ”) + CHAR(39) + ‘ AS ErrorMessage;’

then you can just push the results in via the @query parameter

EXEC msdb.dbo.sp_send_dbmail
@profile_name = ‘_________________________________’
,@recipients = ‘_________________________________’
,@subject = ’_________________________________’
,@body = ‘____________________________’
,@body_format = ‘TEXT’
,@importance = ‘HIGH’
,@query = @Query

The retirement of ADP means I will still be using office 2010 ten years from now.

Linked tables are dumb, sharepoint is dumb.

It’s time for something better than jet, Microsoft !!

select    a.*
from    tblA a
join    tblB b
on        a.DiscoverySerialNo = b.SerialNo
or        a.DiscoverySerialNo = b.DiscSerialNo

You must have noticed that code like this takes longer than usual, or even worse, never returns result.

I haven’t analyze this so cannot tell exactly what the query plan looks like. There are a couple of other ways to achieve the same results without using OR in JOIN ON clause, and they are life savers in terms of improved performance.

One way is to use UNION:

select    a.*
from    tblA a
join    tblB b
on        a.DiscoverySerialNo = b.SerialNo
UNION
select    a.*
from    tblA a
join    tblB b
on        a.DiscoverySerialNo = b.DiscSerialNo

Make sure that UNION does not introduce duplicate matching records because of different values in the selected columns. In another word, using getdate() function in SELECT is not a good idea.

http://bisherryli.wordpress.com/2011/01/06/t-sql-using-or-in-join-on-clause-vs-union/

by default it clears history after 100 lines or something dumb

USE [msdb]

GO

EXEC [dbo].[sp_set_sqlagent_properties]

@jobhistory_max_rows=10000,

@jobhistory_max_rows_per_job=1000

GO

I’ve originally read about the importance of using views 12 years ago when I was playing around with Analysis Services.

I’m starting to finally use this notation- I wish I had start doing this 12 years ago

I just think that naming the columns in the create view statement is more elegant than giving each column an alias.

-Aaron

create view dbo.DWF_INVENTORY_ON_HAND_RealTime
(
[DWF_INVENTORY_ON_HAND_PREFIX]
,[DWF_INVENTORY_ON_HAND_ENTITY_CD]
,[DWF_INVENTORY_ON_HAND_LOCATION_CD]
,[DWF_INVENTORY_ON_HAND_PRODUCT_NUM]
,[DWF_INVENTORY_ON_HAND_ON_HAND_QTY]
,[DWF_INVENTORY_ON_HAND_ON_HAND_VOLUME_QTY]
,[DWF_INVENTORY_ON_HAND_MOVING_AVG_COST_DOL]
,[DWF_INVENTORY_ON_HAND_LAST_COST_DOL]
,[DWF_INVENTORY_ON_HAND_EXTENDED_COST_DOL]
,[DWF_CTRL_DATE_INSERT]

)
As

SELECT ‘SJI’ as Prefix, ENTITY_CD, LOCATION_CD, ITEM_NO, QTY_ON_HAND, VOLUME_ON_HAND, MOVING_AVG_COST, LAST_COST, EXTENDED_COST, GetDate() as InsertDate
FROM DW_Staging_Bluebee.dbo.DWS_BB_INVENTORY_ON_HAND
UNION

SELECT ‘BPB’ as Prefix, ENTITY_CD, LOCATION_CD, ITEM_NO, QTY_ON_HAND, VOLUME_ON_HAND, MOVING_AVG_COST, LAST_COST, EXTENDED_COST, GetDate() as InsertDate
FROM DW_Staging.dbo.DWS_BPB_INVENTORY_ON_HAND_TEMP_LT97

Power View for Cubes

By Ivan Paniagua, 2013/05/21

http://www.sqlservercentral.com/articles/Power+View/97681/

I still cannot believe that this is true.  How can we get someone at Microsoft to verify that this is the intended behavior?

The update adds support for jQueryMobile 1.3 and jQuery 1.9, according to this blog posting from the LightSwitch team. “Embracing the mobile-first, instead of mobile-only, approach was the main focus of this release,” the team states.

The key upgrade to the runtime, it appears from the blog, is the implementation of responsive design. Responsive design automatically resizes an interface according to the screen size of a particular device. (It’s something we did on VisualStudioMagazine.com; we’ve been writing about some of the challenges.)

The update is available through NuGet. The first step is to update the “Microsoft.LightSwitch.Client.JavaScript.Runtime” package, which also grabs the latest supported dependencies. The next step is to increment the version numbers of the JavaScript and CSS files in the default.htm file (the blog specifies which files). Note that you’ll need to do that for every LightSwitch project you have.

http://visualstudiomagazine.com/blogs/onward-and-upward/2013/05/lightswitch-html-client-updated.aspx

In the old days, before calculators, children had to learn to do long multiplication, for example 431 × 27, using pencil and paper. This was a bit of a chore, now largely dropped in favour of tapping the problem into a calculator, which gets the answer more reliably. However, it turns out that the children were learning a lot more by accident than how to multiply long numbers. They were learning to set out their working in an error-displaying form, essentially a twentieth century proof that their answer was correct. They had to be absolutely precise in their working, but if they made a mistake, they could check their working, find the mistake and correct it. Their teachers could periodically take in this work and confirm that their pupils were working accurately and in a proper error-displaying way. Not only all that, but children were intuitively learning something about the mathematical structure of numbers by working with them, so that when they came to polynomials they found that working out (4x² + 3x + 1) × (2x + 7) was not much different to working out 431 × 27. (In fact it’s a bit simpler, because there are fewer carries.) To someone with a calculator, they are entirely different.

I wonder if, in the way we try to teach programming nowadays, we may have fallen into some similar traps, by not realising what students accidentally learned in the past.

For example — and here’s a heretical thought — are languages with GOTO really as bad as we imagine for noviceprogrammers? Dijkstra claimed that “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration”. But don’t forget this was just a claim: where’s the evidence? Dijkstra himself obviously first learned to program in a language with only GOTOs, as I did, and I’m fairly happy that it did us no lasting damage. In fact I think it forced us to think about our code and to work with it in a particular detailed way, and this earlier practice may have served us well later, even when we programed in structured languages.

ARTICLE

http://onfoodandcoding.blogspot.co.uk/2013/04/completely-reliable-conclusions.html

COMMENTARY

http://www.reddit.com/r/programming/comments/1dh9p7/was_dijkstra_wrong_is_goto_good_for_novice/

And since they’ve introduced Availability Groups, and marked database mirroring as deprecated, you’d think they’d make make mirroring available in all editions.  Alas…they don’t…officially anyway.  Thanks to my constant poking around in places I’m not “supposed” to, I’ve discovered the low-level code that implements database mirroring, and found that it’s available in all editions!

It turns out that the query processor in all SQL Server editions prepends a simple check before every edition-specific DDL statement:

IF CAST(SERVERPROPERTY('Edition') as nvarchar(max)) NOT LIKE '%e%e%e% Edition%'
print 'Lame'
else
print 'Cool'

If that statement returns true, it fails. (the print statements are just placeholders)  Go ahead and test it on Standard, Workgroup, and Express editions compared to an Enterprise or Developer edition instance (which support everything).

Once again thanks to Argenis Fernandez (b | t) and his awesome sessions on using Sysinternals, I was able to watch the exact process SQL Server performs when setting up a mirror.  Surprisingly, it’s not actually implemented in SQL Server!  Some of it is, but that’s something of a smokescreen, the real meat of it is simple filesystem primitives.

The NTFS filesystem supports links, both hard links and symbolic, so that you can create two entries for the same file in different directories and/or different names.  You can create them using the MKLINK command in a command prompt:

mklink /D D:\SkyDrive\Data D:\Data
mklink /D D:\SkyDrive\Log D:\Log

This creates a symbolic link from my data and log folders to my Skydrive folder.  Any file saved in either location will instantly appear in the other.  And since my Skydrive will be automatically synchronized with the cloud, any changes I make will be copied instantly (depending on my internet bandwidth of course).

So what does this have to do with database mirroring?  Well, it seems that the mirroring endpoint that you have to create between mirror and principal servers is really nothing more than a Skydrive link.  Although it doesn’t actually use Skydrive, it performs the same function.  So in effect, the following statement:

ALTER DATABASE Mir SET PARTNER='TCP://MyOtherServer.domain.com:5022'

Is turned into:

mklink /D "D:\Data" "\\MyOtherServer.domain.com\5022$"

The 5022$ “port” is actually a hidden system directory on the principal and mirror servers. I haven’t quite figured out how the log files are included in this, or why you have to SET PARTNER on both principal and mirror servers, except maybe that mklink has to do something special when linking across servers.  I couldn’t get the above statement to work correctly, but found that doing mklink to a local Skydrive folder gave me similar functionality.

To wrap this up, all you have to do is the following:

1. Install Skydrive on both SQL Servers (principal and mirror) and set the local Skydrive folder (D:\SkyDrive in these examples)
2. On the principal server, run mklink /D on the data and log folders to point to SkyDrive: mklink /D D:\SkyDrive\Data D:\Data
3. On the mirror server, run the complementary linking: mklink /D D:\Data D:\SkyDrive\Data
4. Create your database and make sure the files map to the principal data and log folders (D:\Data and D:\Log)
5. Viola! Your databases are kept in sync on multiple servers!

One wrinkle you will encounter is that the mirror server will show the data and log files, but you won’t be able to attach them to the mirror SQL instance while they are attached to the principal. I think this is a bug in the Skydrive, but as it turns out that’s fine: you can’t access a mirror while it’s hosted on the principal either.  So you don’t quite get automatic failover, but you can attach the files to the mirror if the principal goes offline.  It’s also not exactly synchronous, but it’s better than nothing, and easier than either replication or log shipping with a lot less latency.

I will end this with the obvious “not supported by Microsoft” and “Don’t do this in production without an updated resume” spiel that you should by now assume with every one of my blog posts, especially considering the date.

http://weblogs.sqlteam.com/robv/archive/2013/04/01/database-mirroring-on-sql-server-express-edition.aspx

And I’ve been using SQL Server for a long time.. but even I sometimes have embarrassing gaps in my knowledge about SQL Server.

This is one of those situations.. I cannot believe that I didn’t realize (until just a few months ago) that we could use CROSS APPLY without a function.

I’m utterly amazed by this, it’s a better method that what I was previously doing.. For the record, I was previously in the habit of returning the input parameters in the function so that I could join on it.

CROSS APPLY

(SELECT POMatQty = COALESCE(SUM(T.QTY),0),

POMatMBF = COALESCE(SUM(T.total_BF*0.001),0)    — No Nulls…

FROM TRANSACT AS T

WHERE      T.TRAN_CODE = ‘PO’

AND T.TYPE = ‘PORECPT’

AND T.LOC = L.LOC                   — Constrain sub-select to out record…..

AND [T].[ITEM_NO] = LEFT([L].[ITEM_NO],13)+’900′   — …. Loc and Item_No

AND T.TRAN_DATE BETWEEN CAST(DATEADD(MM,-@MonthsMAT,GETDATE()) AS DATE)

AND CAST(GETDATE() AS DATE) –NO FUTURE SALES

) iTVF3

Embrace, extend, extinguish: How Google crushed and abandoned the RSS industry

Summary: Most of the commentary I’ve read so far about the loss of Google Reader has been about its use as an RSS client. But that’s a red herring. The real victims were companies that had planned in 2005 and 2006 to build RSS sync engines. Google stomped them out of business like Godzilla sweeping through Tokyo.

I know those details because the team responsible for developing Google Reader blogged about their progress regularly beginning with that first “Hello, Internet” post more than seven years ago.

The most recent post on The Official Google Reader Blog came earlier this month, when the company announced it was “Powering Down Google Reader.” The stated reason? According to Google’s Alan Green, “usage of Google Reader has declined, and as a company, we’re pouring all of our energy into fewer products.” It was all just one bullet on a longer “spring cleaning” post at the Google Official Blog.

It wasn’t always that way, though. In fact, the short life and sad death of Google Reader tells a familiar story of how Google swept into a crowded field, killed off almost all credible competition with a free product, and then arbitrarily killed that product when it no longer had a use for it.

It’s not unlike the widely criticized model that Microsoft pursued in its pre-Millennium days as a monopolist: Embrace, extend, extinguish. Except in this example it doesn’t appear to be part of a grand plan to destroy an industry. Google was Godzilla, sweeping through the landscape and crushing anything in its path, because few startups can compete with a free product from Google.

Image credit: Classical Iconoclast

Most of the commentary I’ve read so far has been about the loss of Google Reader as a client. But that’s a red herring. It’s easy to write an RSS client, which is why so many alternatives have emerged since the surprise announcement.

No, Google Reader’s real competition back in its early days was not client software but services that aggregated RSS feeds and synchronized them across multiple devices. In 2005, when Reader started, Bloglines owned this space (although they weren’t very good it) and an upstart called NewsGator was also aggressively working to provide a central repository for RSS feeds as a service.

Google’s entry into this market decimated those companies and forced them to pivot or die. Ironically, the people who built Google Reader provided the death notices for both of those competitors.

Throughout 2006 and 2007, while Google Reader was still officially a beta under the Google Labs label, the team in charge of development was busy attracting third-party development support, including external tools and a WordPress plugin. A February 2007 post documented Google’s success at getting publishers to embrace and promote Google Reader.

In May 2007, more than 18 months after its release, Google Reader was still officially a beta, but that didn’t stop the team from offering offline support for Google Reader:

To do this, we’ve used the newly released Google Gears, a browser plugin that enables offline web applications. Once you’ve installed Google Gears, you can download your latest 2,000 items so they’re available even when you don’t have an internet connection. To get started, simply click the “Offline” link in the top right of Google Reader.

A small note of warning: the current version of Google Gears is a developer release. Given this, you may notice a few kinks here and there, but we’ll be working hard to iron those out over the coming months.

Spoiler alert: Google abandoned Google Gears (and thus dropped offline support in Google Reader) three short years later.

Google Reader came out of beta in September 2007. Normally, that would be a sign of commitment, but apparently Google management never really bought into Reader and it was on the chopping block for years.

In September 2008, Google talked about how it was using big-name journalists to endorse Reader by creating their own custom shared news feeds, called bundles, to Google Reader. That effort continued throughout 2009, with heavy-hitter endorsements from Arianna Huffington and Thomas Friedman and Paul Krugman as well as the editors of Lifehacker, Boing Boing and Kottke.

NewsGator surrendered to Google in July 2009, pivoting to a focus on enterprise customers after seeing their core business crushed. Such happy talk!

A hearty welcome to NewsGator users

A little while back, our friends over at NewsGator told us that lots of people who use their client RSS readers like FeedDemon and NetNewsWire had been asking for the ability to synchronize with Google Reader, since maintaining two separate subscription lists was a hassle. Today, we’re happy to report that we’ve worked with NewsGator to make this possible, and new versions of their client readers released today will use Google Reader as the synchronization backend. If you use one of these applications, check out NewsGator’s instructions and FAQ on transitioning your subscriptions.

Now that Google Reader can be used as the online companion to NewsGator’s client applications, they’ve decided to discontinue consumer use of NewsGator Online, their free web-based RSS reader, at the end of August. If you’ve been using this service, you’ll need to transition your subscriptions to Google Reader…. To those of you who have been waiting for this integration and to those of you who are using Reader for the first time, welcome!

It’s a shame, really, because NewsGator was committed to building a business around the back end of RSS. In a statement published in 2005, a few months before Google stomped in, NewsGator’s Greg Reinacker had laid out an ambitious roadmap:

One thing that’s definitely coming (and some of these already exist, although haven’t yet been made public) is extremely deep API support.  Our general plan here is to expose nearly everything in NewsGator Online via API, and allow folks to build applications that leverage our platform in unique ways. Anything from simple notifiers, to complete aggregation applications, to some new kinds of apps that haven’t ever been built yet, will be possible using our API’s.  This is a pretty exciting area — watch over the next few months as we start rolling these out.

In a story filled with irony, the announcement in May 2010 that Google was discontinuing offline access via Gears came with a suggestion that customers switch to two other NewsGator products instead (as well as a third for Linux)

Of course, we know that offline access is important to some of you, and with the wide range of third party clients that sync with Google Reader, you don’t need to give it up. Depending on your operating system, we recommend taking a look at:

• NetNewsWire (Mac OS X)
• FeedDemon (Windows)
• Liferea (Linux)

Each of these alternatives will sync your subscriptions and read state with Reader, and continue to provide offline access to your feeds. … We realize that removing features and support is not easy, but with this spring cleaning done, we’ve laid the groundwork for more Reader improvements down the line. We apologize for any inconvenience….

There’s that “spring cleaning” again.

So, after gutting NewsGator’s original business model, Google encouraged the company to use its back end as a synchronization engine, which it then abandoned a few years later. Anyone who’s in the business of developing apps or services based on Google products should take note.

And then in September 2010 came the other obituary:

The Reader team was saddened to hear that Bloglines will be shutting its doors on October 1. Bloglines was a pioneer in the feed reading space, and for Web 2.0 in general.

We know that nothing will be quite like Bloglines in the hearts of its users, but if you’re looking for another online feed reader, we encourage you to give Reader a shot. All you need is a Google account … It’s also very easy to bring your Bloglines subscriptions over, you just have to export them from Bloglines and import them into Reader.

That post was accompanied by a graphic showing the impressive growth in Reader usage. Oddly, the graph didn’t include actual numbers, only a steadily increasing line showing relative growth.

The end of the road for Google Reader began on October 20, 2011, with yet another post in which the Godzilla of Mountain View announced it was “important to clean things up a bit.” (Note to Google partners: If you hear the word “cleaning,” your business is the trash that’s being taken out.)

In the next week, we’ll be making some highly requested changes to Google Reader. First, we’re going to introduce a brand new design (like many of Google’s other products) that we hope you love. Second, we’re going to bring Reader and Google+ closer together, so you can share the best of your feeds with just the right circles.

[…]

We recognize, however, that some of you may feel like the product is no longer for you. That’s why we will also be extending Reader’s subscription export feature …. Your data belongs to you, after all, and we want to make sure you can take it with you.

And then, after an 18-month gap, the other shoe dropped on March 13, 2013:

Powering Down Google Reader

We have just announced on the Official Google Blog that we will soon retire Google Reader (the actual date is July 1, 2013). We know Reader has a devoted following who will be very sad to see it go. We’re sad too.

There are two simple reasons for this: usage of Google Reader has declined, and as a company we’re pouring all of our energy into fewer products. We think that kind of focus will make for a better user experience.

To ensure a smooth transition, we’re providing a three-month sunset period so you have sufficient time to find an alternative feed-reading solution. If you want to retain your Reader data, including subscriptions, you can do so through Google Takeout.

What’s fascinating now is that the entire RSS industry is being rolled back to about 2006 and asked to start over. All those clients that relied on Google’s sync engine? They’re back at Square One.

Like NetNewsWire on the Mac, NewsGator returned to its original owner after its consumer RSS business was gutted by Google. Developer Daniel Pasco wrote this post in the wake of the Google announcement:

Given the discontinuation of Google Reader, I wanted to take a moment to talk about our plans for NetNewsWire.

First, we intend to bring sync to future versions of NetNewsWire. It’s too soon to go into details about this, but you should know that we recognize how extremely important it is and that it is a top priority for us.

Wisely, the developers of that product have decided not to make the same mistake twice. They’ve dropped their plans to rely on Apple’s iCloud.

Meanwhile, the news is not so good for the other NewsGator alumnus, FeedDemon for Windows. Developer Nick Bradbury says “it’s time for FeedDemon to die”:

If you’re an avid FeedDemon user, you probably know that I’ve struggled to keep it updated. FeedDemon stopped “paying the bills” a while ago, so I took a full-time job elsewhere and haven’t been able to give FeedDemon the attention it deserves.

Then today came the news that Google Reader is shutting down on July 1. FeedDemon relies on Google Reader for synchronization, and there’s no decent alternative (and even if there were, it’s doubtful I’d have time to integrate with it, at least not without trading time away from my family – which I won’t do).

That was the nail in the coffin for me. I hate to say goodbye to FeedDemon after a decade of working on it, but it’s time to say goodbye. When Google Reader shuts down on July 1, FeedDemon will also disappear.

In an era of mobile devices, where synchronizing content and settings between multiple locations is a crucial feature, losing Google’s sync platform is literally a killer.

Remember how NewsGator was going to build that sync platform years ago? We’ll never know what might have been, but it’s a dead certainty that Google’s entry into the market made that business untenable.

Of course, Twitter and Facebook made a very large dent in the usage of RSS, but there’s still a market there. A big one, in fact, if measured by the standards of a business that’s not Google-sized.

And now, with Google abandoning that service, any business that uses RSS gets to go back to the glory days of 2006. Ugh.

Back in 2009, when NewsGator surrendered to Google, I wrote this:

[S]elfishly, I’m glad Google has won. It’s the default online RSS reader, and I think they’ve done a fine job with it. I can still use FeedDemon and NetNewsWire on Windows PCs and Macs respectively.

[...]

In the bigger picture, I hate being beholden to Google for yet another service where they can watch what I do and who I watch. But I’m willing to trust them, just as I’m willing to trust Microsoft on many issues.

Fool me once…

http://www.zdnet.com/embrace-extend-extinguish-how-google-crushed-and-abandoned-the-rss-industry-7000013025/

Here are 20 different hashes for the phrase “hello world”

MD2:
195D5B5475EC3E6760F888511F20B84D

MD4:
2F34E7EDC8180B87578159FF58E87C1A

MD5:
3E25960A79DBC69B674CD4EC67A72C62

SHA0:
985467135DE409D2E200621651227C07158B3A93

SHA1:
7B502C3A1F48C8609AE212CDFB639DEE39673F5E

SHA224:
AC230F15FCAE7F77D8F76E99ADF45864A1C6F800655DA78DEA956112

SHA256:
64EC88CA00B268E5BA1A35678A1B5316D212F4F366B2477232534A8AECA37F3C

SHA384:
9203B0C4439FD1E6AE5878866337B7C532ACD6D9260150C80318E8AB8C27CE330189F8DF94FB890DF1D298FF360627E1

SHA512:
B7F783BAED8297F0DB917462184FF4F08E69C2D5E5F79A942600F9725F58CE1F29C18139BF80B06C0FFF2BDD34738452ECF40C488C22A7E3D80CDF6F9C1C0D47

RIPEMD:
2CD9C3A065765D918B6BB820D242E210

RIPEMD128:
8E62422E18DF3F3605B1C1BAB9D1A887

RIPEMD160:
DBEA7BD24EEF40A2E79387542E36DD408B77B21A

RIPEMD256:
939E606F4BA58C9D9CE1BF4087554525AC60530B4B4DC8DF76652F831CF49516

RIPEMD320:
2160B4FE31F813597EDC31DAD608E7A875FF90FD08418AF80F1406B0DC8184B3F07F8EBE1A4EF318

Tiger:
1F5D29E51FB59E6247561E19A0E593DAC8330180322881C4

Whirlpool:
69059B5A5AFE634B484DA83034CE906343D453A6006C1119B1EE8963B4836396AEA8B5565E9F67EECA7B08E608E79E7986A109151B0FF3267827722E7E1B1AB4

RadioGatun32:
978C62970368C35ACD8E7A6981EF1FA83A9D42A841FD735316DA18F429841824

RadioGatun64:
3D54791DDD4E34CABBA5136791D7CB6067D2D6E307C9DD85F6E1E3297657E03F

Grindahl256:
151DB4A20E19776EC8D1AC20A8BFE3D33C54318A3B35FB9EF99097E8A35ED38A

Grindahl512:
72FFD99278434B64A36BC8CCAACC3FC2F0546D468E61C9216B5EDAFE707F3D4B1ADFDC9536C7DCE6544442880084AC674471C98FAD0AD3A0B49F69E96529718D

Snefru(4, 128):
0531E509480CFE53F8E2FF137496690E

Snefru(8, 128):
2AFE4AFD3DC87785DA6D55861C5FC943

Snefru(4, 256):
E8ED4B37C3320D48358631F4A7A571F701DF5876CCF634FC0E2DC95AA8103217

Snefru(8, 256):
AAEB620B7DE3291A73C647C96E91D17774A2ED37569C4BBD6E698B8D715ABB19

http://sqldom.sourceforge.net/

I’m SUPER excited to get home from work today, because there is a new version of this sproc (with better NOCOUNT) that can decrease execution time from ~60s to ~2s.

-Aaron Kempf

——————————————————————————————-
Aaron,
FYI, I posted an update to SQLDOM today on Sourceforge (.927). http://sourceforge.net/projects/sqldom/files/SQLDOM_core_927.sql/download

Besides adding a parameter to allow retrieving a subset of the HTML from the DOM, I found that if the caller did not have SET NOCOUNT ON that the SQLDOM procedures could run much more slowly than expected. (For example, instead of processing a page like http://www.ocregister.com in 4 seconds, it could take like 30 seconds.)

This version explicitly sets SET NOCOUNT ON in each procedure to avoid the risk of this condition.

http://www.reddit.com/r/programming/comments/1ac5cx/huginn_an_open_source_ifttt_yahoo_pipes/

http://vitobotta.com/percona-xtradb-cluster/