Just got func'ed by an alien.

Talking about embedding (hosting) PowerShell for testing or other purposes could be useful. Also general use for testing. PowerShell for extending objects (adding properties and methods) is interesting too...

Nonsense, if the application uses the view I mentioned then the application can have boolean everywhere while the database has CHAR(1).

Harder why? Why not have views for the application that show bit types while the table has CHAR(1)? Why is the "database storage for the application" instead of the "application is a GUI for the database"?

Hooray, a useful comment in this thread! Bit type sucks if you even plan on changing your application in the future. App code should not care what the underlying type is anyway so what is the problem here?

In this case, the best thing to do after the project has finished is to update your resume! ;)

Yeh, but you have to compare this table against a table of "How many days in the year you are forced to work for the government for free" - i.e. taxes. Also, vacation days are negotiable with your employer.

Copy and pasted from some notes I made once...

Microsoft .NET Framework 3.0 (2.8Mb initial plus 30Mb during the install) is here (release notes).

If you have installed a pre-release .NET 3.0, there are instruction on the release notes page to help uninstall it including a link to  .NET 3.0 pre-release uninstall tool.

Some general information here:
http://www.informit.com/articles/article.asp?p=659520&seqNum=1&rl=1

Free training: http://go.microsoft.com/?linkid=5578179

Note that .NET Framework 3.0 = .NET Framework 2.0 + WF + WCF + WPF + WCS (see here) - i.e does not include C# 3.0 which is 'Orcas' timeframe.

As far as Visual Studio 2005 goes, you need to install the Windows .NET Framework 3.0 SDK for Vista (is OK on XP SP2).  This is a big download (1.4Gb iso file) so find an existing DVD copy!  There are specific "Visual Studio 2005 extensions" for [W]WF, and WCF/WPF.

Mark Nischalke wrote:

But the good news is I'm just a consultant, I don't have to stay after the project is finished.

Aha! You do realize that as soon as you go all the changes you did that the guy didn't like are going to be reverted?! Just take the check and move on... :suss:

I guess a lot of people have commented already. I bought it based on all the positive commentary around on the book, then I looked through it and realised that I had just wasted my money. I would recommend it to anyone gettting into programming as a profession, but for anyone with a more than a couple of years experience (and having worked on more than two projects) I'd say skip it and invest your reading time elsewhere. Perhaps stop by the library and flick through their copy first.

yuk.... it's all a matter of taste I guess. There is huge industry in publishing tidbits about celebrities so why not popular bloggers: "B(log)TV", "Lifestyles of the worn-out keyboarders", "Chris Sells linqed with Aguilera". Part of the art of blogging is self-promotion so it's all just a matter of time. It reflects on the ego of the blogger and the demand (and patience) of the blogsumer.

I agree, I like procs too, I'm not saying they are slower at all. I think a proc-based design 'architecturally scales' better (my buzzphrase for the day). On projects I get paid to work on, I would only use dynamic SQL as a last resort. On the other extreme, on a different type of project where I think an off-the-shelf ORM could do the job, I'd use one (not happened yet but only because of fate).

I can understand your situation now. But your post talks about all commercial projects. In our current scenario (not an in-house project) we have a >10 years young system with 100s of clients in only a few countries. There used to be problems with some stored procs being changed... but mostly only by our own 'onsite' consultants! (Encrypting the procs certainly reduced that problem on another project I worked on though it is not done here if only to allow consultants to make rapid changes as need be.) But for us, managing dynamic sql pushed from tens of disparate applications has been a historic nightmare (gridlocking data model changes) that we are moving away from.

But why would this malicious person bother doing that if they can just edit the data directly in the database?

Yeh, but the point it that you're trying to have your cake and eat it too. You can't give a user high levels of security rights (so they can modify or replace stored procedures - encrypted or not) and then pretend that by embedding your SQL in the exe that you are gaining anything in this regard when the same user can very easily do anything they want (with these rights) directly on the db or even use SQL Profiler to grab your SQL and play with it in Query Analyzer.

Sure. But how is this any different to your executable with embedded SQL? As long as your user has a sysadmin login there's nothing can do to stop a determined user doing what they want with.

One case that makes sense is when the execution plan of the proc (at least of the static SQLs within it) is compiled according to the set of parameters the proc is called with when doing the (first) compilation. This may not necessarily be the best plan (to get the desired result) in other cases. I imagine unchanging dynamic SQL (text the same, but parameterized) is the same. However, dynamically structured SQL (not just parameterized SQL but changing the actual text) is recompiled with each new SQL (text) so the plan can reflect the actual query. This probably only makes sense if the original stored proc is structured to handle multiple scenarios (e.g search permutations) while composing case-specific dynamic SQL would be leaner and produce a better execution plan. E.g. the stored proc could have lots of 'OR's and joining on too much to cover every parameter scenario, like a general purpose search procedure with lots of parameters. There might be too many search permutations to have a proc for each one, whereas dynamic SQL's recompilation overhead could be less than the benefit of a better executition plan.

I agree, every project I worked on that used stored procedures had them in source control. (So far only by managing them as individual (*.sql) files rather than taking advantage of any integration features.)

If using SQL Server, you can encrypt the stored procedures so they cannot be edited.

If your guide can talk seriously about coupling and manage to conclude that exposing your relational object model to your client applications is a positive (without distracting to strawman performance discussions), I will buy it.