okay, so it isn’t really a fix, but should be.
today the team released the SqlTableProfileProvider which modifies the profile storage mechanism from colon-delimited blobs (which provide for challenging backend reporting) to a method where each property is realized as a separate column.
is this the best implementation? maybe not. a quick look at the docs shows that the table has to be created in advance. one flexibility thing i love about the providers is just that…the flexibility. in the out-of-box profile provider you can implement new profile properties at will, and not have to touch the database. what this new implementation does is better store the data for reporting, however removes that quick flexibility — the table would have to be altered each new profile property.
a good start to better storage of that data though!
one gotcha: data isn’t serialized and must be compatible with the storage type.
go check out the SqlTableProfileProvider and SqlStoredProcedureProfileProvider
also be sure to check out this implementation ASP.NET 2.0 Custom Profile Provider as this is closer (and perhaps great — i haven’t tried it) to what I’d be looking for. the data may not be as easy to report on as above, but certainly simpler than colon-delimited.