Old news to many, but Google has a Charting API that allows the creation of numerous chart types via a formatted URL string. The Google Chart API returns a .PNG file which is easily embedded in an image tag. If you want to embed charts into your web applications, this chart API might help get you to market quicker.

The idea is simple enough - create an API which returns an image given a specially formed URL. Values can be specified in-line, or encoded to make them more manageable. There are too many chart types and options to document here, but Google's documentation for this API is pretty extensive. I'm impressed with the approach and simplicity. I'm also impressed with the breadth of chart types and the number of options available. In general - they just look plain cool!

Although the API is pretty easy to drive natively, there is also a .NET Helper Library called ngchart which simplifies the API's from native .NET code.

Enough talk - some examples -

http://chart.apis.google.com/chart?cht=p3&chd=s:Uf9a&chs=250x100&chl=January|February|March|April

http://chart.apis.google.com/chart?cht=v&chs=200x100&chd=t:100,80,60,30,30,30,10

http://chart.apis.google.com/chart?chs=225x125&cht=gom&chd=t:70&chl=Hello

http://chart.apis.google.com/chart?cht=lxy&chs=200x125&chd=t:0,30,60,70,90,95,100|20,30,40,50,60,70,80|10,30,40,45,52|100,90,40,20,10|-1|5,33,50,55,7&chco=3072F3,ff0000,00aaaa&chls=2,4,1&chm=s,FF0000,0,-1,5|s,0000ff,1,-1,5|s,00aa00,2,-1,5

http://chart.apis.google.com/chart?chco=f5f5f5,edf0d4,6c9642,365e24,13390a&chd=s:fSGBDQBQBBAGABCBDAKLCDGFCLBBEBBEPASDKJBDD9BHHEAACAC&chf=bg,s,eaf7fe&chtm=usa&chld=NYPATNWVNVNJNHVAHIVTNMNCNDNELASDDCDEFLWAKSWIORKYMEOHIAIDCTWYUTINILAKTXCOMDMAALMOMNCAOKMIGAAZMTMSSCRIAR&chs=440x220&cht=t

In the previous articles on dFM, we covered the basic concepts and how to determine the basic factors. This posting explains a simple process for building a matrix from these factors that will allow you to "cost" a scenario. A "scenario" is an option for building and architecting a software application. We then score this scenario using a score-card (described here), to compare the various scenarios.

This is a common weighted scoring system for decision support. Its not a perfect system; the subjective weighting are controlled to a degree by a democratic voting system, but a single factor could still play an unfair pivotal role in a final score for a potential scenario. This technique is shown to spark some ideas, not as a prescriptive technique.

Step 1 -  Brainstorm a set of factors that influence - cost, time, performance, security, and reliability.

Step 2 - Group similar factors under a topic heading

Many of the brainstormed factors can and should be measured by one metric. An example might be the number of web servers, and the number of database servers. This can be joined under the single topic heading "Number of Servers Required"

Step 3 - Build the "Scoring Matrix" for each group.

The complexity in this step takes an absolute measurement and maps it to a simple 1 to 5 score. All measures should be 1 being lowest "cost, effort, time, best performance, most secure, most reliable" and 5 being the opposite direction.

(These are just very simple samples. The list and scores are completely fabricated in this picture)

Step 4 - Determine the factor weightings (what is more important than what)

I have three basic approaches for this -

  a) You just decide relative importance and allocate weightings subjectively! Great if you can get away with it, but the intention of Design for Manufacturing is to find the "best" design from a balanced set of design objectives. If we just designed software for ease of development, we may not fully consider the operational aspects and the cost of ownership over time.

  b) Paired Options (or Pairwise comparison): Get the group of people representing different domains of expertise (operations, development, business, marketing, sales) together again and have them vote A versus B, A versus C, etc. to determine what is more "important" to that person. Take an average measure of the room (more think A is more important than B). Total up the number of votes for each factor, and determine what percentage that total is of the entire selection. % weight = (count / total pairs (15) ) * 100

  c) * my preferred* Stack ranking: Get each representative from each domain specialist (operations, developers, business, storage, etc) to stack rank the factors, most important to least important. This will uncover and account for individual biases. It is my preferred method because it also allows people to say "No Impact" for a specific factor on a "perspective" of the factor. Total up the relative ascending score (assign 1 to the lowest row that was a factor, and 2 to the next one up, and so on) and determine what percentage that score is of the total points available. This will look something like this -

Consider doing this for more than one perspective. E.g. As far as Cost, how would you rank importance. As far as time to market, how would you order these factors. What you are looking for is a way to mathematically represent that one factor has a much higher impact on a desired delivery "factor". Some axis of ranking might be:

    1. Capital expenditure - Upfront cost

    2. Operational Expenditure - Ongoing costs

    3. Time to market - How quickly can it initially be developed

    4. Performance - hitting agreed service and performance levels

    5. Security - what factors make a system more secure

    6. Reliability and Stability - what factors make a system able to handle failure more gracefully)

Whatever method you employ, the outcome needs to be a table of the factors, and a weighting multiplier, E.g.

    Number of Servers Required - 24%

    Bandwidth - 20.6%

    Searches / sec - 10.3%

    Number of Deployment Items - 17.2%

    Number of Third Party Components - 13.7%

    Number of Features - 13.7%

Step 5 - Score a Scenario and Multiply By Weights

Break out excel. Use the scoring sheet from Step 3 to score a scenario. Multiply each score by the weights determined in Step 4. Total all of the weighted scores. Do this for other scenarios to compare.

In the next installment of this article series, i'll demonstrate this basic technique with some real examples and prepare a final spreadsheet template you might find useful in doing your own option analysis.

Troy.

I had a need to execute a SQL statement using LINQ to SQL. Its a long story, but I couldn't use the LINQ to SQL Designer because I was calling a SQL Server 2005 System View. So, I just decided to use the DataContext.ExecuteQuery method. It was a welcome surprise when the intellisense tooltip filled the screen for the first parameter "elementType" -

Actually, the tooltip really helped. It explains the rules and priority of how the return resultset is mapped to the type you specify. To paraphrase, even though my type doesn't have LINQ to SQL attributes on each property, the system will still attempt to match properties to result columns using a variety of methods.

1. If a field or property is matched to a specific column name, that column is expected in the result set
2. If the field or property is not matched, a column is expected with the same name in the result set (first Case Sensitive search, then case in-sensitive search)

It goes onto specify the rules about change tracking, primary keys, etc.

A lot to read, but definitely saved me a having to hunt around for the necessary information. Nice work to whoever spent the extra time going to this detail; it shows they really thought about what someone would need when they used this method for the first time.

It could have been "elementType: The element type." if i'd been writing it :-)

Troy.

Its often difficult on large projects to keep track of all the additions as a system grows. When a project grows, it gets more difficult to keep all system drawings accurate and correct. If a drawing isn't automatically generated, then you can have little faith that it is absolutely up-to-date.

The alternative is to write tools that examine the code and draw representations of the systems continuously. This can be part of a nightly build, or a tool that can be run on-demand in order to make better decisions, resolve design issues early, and identify impact of changes.

In this instance I was having trouble keeping up with what Web Services we had; What Stored Procedures they relied upon, and what SQL Server tables those Stored Procedures depended upon.

The application we wrote in a couple of days simply hunts through all *.cs files and uses Regular Expressions to find applicable code. It then uses Microsoft Research's Graph Drawing Tool "GLEE" to visually represent it. GLEE is incredibly easy to use and integrate. The following screen-shot (with the sensitive names removed) took less than 15 lines of code to produce (and a few hundred to do the Regular Expression hunting).

A side-benefit of this tool is that it forces the team to conform to the coding standards. If they want their new code to be incorporated into the latest drawings, follow the patterns provided.

Its great to come into work each morning and see what has been added, and to ensure that the cross-coupling even at the database level isn't going to cause use duress later in the project. We can quickly see what a DB schema change will impact. Sleeping much better now....

Troy.

Finding what dependencies a Stored Procedure has on underlying tables, views, functions, etc is often necessary when trying to assess the impact of a change. SQL Server has built-in functions that will indicate in most cases a dependency for any object in the database. The system view "sys.sql_dependencies" is viewed with skepticism by some people who have obviously been bitten in the past.

In order to see for myself the results, I wrote a simple helper class, and thought i'd share the boilerplate code to start you off here (I may clean it up and share it as a library, email me if you have difficulty getting it running). Its a rough prototype, but it is returning good results for my purposes.

Note: This code requires Visual Studio 2008. It uses LINQ to SQL in a very loose way due to the LINQ to SQL Designer not listing the System Views and Functions. Its a good example of just how flexible LINQ to SQL is though.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Linq;
using System.Configuration;

namespace DatabaseDependencyCrawler
{
    public class SysDependsResult
    {
        public int referenced_major_id { get; set; }
    }

    public class ObjectInfoResult
    {
        public int id { get; set; }
        public string name { get; set; }
        public string xtype  { get; set; }
        public DateTime crdate { get; set; }
    }

    public class DatabaseDependencyCrawler
    {
        public List<DatabaseDependencyEntity> GetDBObjectDependencies(string connectionString, string name)
        {
            // the system views built-into SQL Server 2005
            string dependsQuery = "select referenced_major_id from sys.sql_dependencies where object_id = object_id('{0}')";
            string objectInfoQuery = "select * from sys.sysobjects where id in ( {0} )";

            List<DatabaseDependencyEntity> result = new List<DatabaseDependencyEntity>();

            // find the list of dependencies based upon a database object's name
            DataContext context = new DataContext(connectionString);

            var dependencies = (IEnumerable<dependencies>)context.ExecuteQuery(
                typeof(SysDependsResult),
                string.Format(dependsQuery, name), 
                new object[] { });

            // build a list of object_is's to we can ask for their name in a second query
            StringBuilder ids = new StringBuilder();
            foreach (SysDependsResult d in dependencies)
            {
                if (ids.Length > 0)
                     ids.Append(",");

                ids.Append(d.referenced_major_id);
            }

            // if any records were found...lookup the names of those id's comma separated
            if (ids.Length > 0)
            {

                IEnumerable<ObjectInfoResult> objects = (IEnumerable<ObjectInfoResult>)context.ExecuteQuery(typeof(ObjectInfoResult),
                    string.Format(objectInfoQuery, ids.ToString()),
                    new object[] { });

                foreach (ObjectInfoResult o in objects)
                {
                    result.Add (
                        new DatabaseDependencyEntity {
                            DatabaseConnectionString = connectionString,
                            SourceObject = name,
                            Dependent = o
                        });
                }
            }
        
            return result;
        }
    }
}

Old news to many, but I had a need to share my desktop today for a conference call. I remembered Microsoft had ShareView coming out of beta, so I downloaded it and was up and running in a few minutes. Its well worth your time having installed. For demo'ing a website prototype to external people, it worked great.

Microsoft ShareView download

Microsoft ShareView Connect Page

Overview

• Hold more effective meetings and conference calls
• Connect with up to 15 people in different locations and get your point across by showing them what's on your screen.
• Work together in real time
• Share, review, and update documents with multiple people in real time.
• Use when and where you want
• SharedView is easy to use, from anywhere, at a moment's notice.

I can see this coming in useful for all sorts of ad-hoc collaboration. I'd like to know how it goes as a remote pair-programming platform as well.

Troy.

I dropped by the ADO.Nets team stands at TechEd 2008 and saw a demo of a new project called "Velocity". It is a distributed caching technology, that allows in-memory caching across a distributed set of machines that is resilient and fast.

Although not on schedule for RTM release until 2009, this technology hold promise for scenarios like distributing reference data, and session state across multiple machines in a server farm.

Anil Nori and Muralidhar Krishnaprasad presented a session on the topic and posted their TechEd slides here. Here is the "What Is slide" -

More resources -

The Velocity team blog

Velocity Project Page

CTP 1 Download

Troy.

I found a good set of programming, and software development quotes. Here is a short-list of my favorites I found at this site. If you know of any other good programming quote websites, leave a comment.

"The Six Phases of a Project:

• Enthusiasm
• Disillusionment
• Panic
• Search for the Guilty
• Punishment of the Innocent
• Praise for non-participants"

Anon

"Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why - Programmers combine theory and practice: Nothing works and they don't know why."

Anon

 

"Good judgement comes from experience, and experience comes from bad judgement."

Fred Brooks

 

"The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time."

Tom Cargill

 

"Learning is not compulsory. Neither is survival."

W. Edwards Deming

 

"Two things are infinite: the universe and human stupidity; and I'm not sure about the universe. "

Albert Einstein

 

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight. "

Bill Gates

 

"The perfect project plan is possible if one first documents a list of all the unknowns. "

Bill Langley

"There are two ways to write error-free programs; only the third works. "

Alan J. Perlis

"Without requirements or design, programming is the art of adding bugs to an empty text file."

Louis Srygley

"I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone."

Bjarne Stroustrup

"There are only two industries that refer to their customers as "users". "

Edward Tufte

"We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. "

Larry Wall

"As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs."

Maurice Wilkes discovers debugging, 1949

I've just been reading a well thought out article on Option Theory applied to software - "Real Options" Underlie Agile Practices, posted by Chris Matts and Olav Maassen.

I like the concept, and its common sense approach resonates well with my beliefs. I'll try and summarize, but you should read their article for the full story.

There are three possible decisions when faced with an option (in our case, an approach, an architectural choice, an implementation choice, etc) -

1. Yes
2. No
3. No Decision Yet

The 3rd choice is often overlooked and a decision is made earlier than it needs to be, curtailing any chance that you will learn more information and make a superior choice later on. The authors explain that when listing options, it is important to define when the true "must have a decision point is" for each option, and passing one of those "drop dead" points is actually making a decision "No" for an option.

The key points for me from this article were:

1. List options early, and keep looking for new options
2. Determine what the true last possible time an option is still viable, and regularly assess if these change due to other decisions
3. Make a solid "Yes" decision for an option at the last possible moment - this leaves open the opportunity for newer options to emerge

I came across this article by looking up the speakers at a local upcoming conference in Seattle. The authors are speaking at the APLN Agile Leadership Summit in Seattle (July 17-18).

Troy.

What are factors?

Factors represent an issue, or a requirement that has an impact on the final "cost" of a product. In electronics, a "cost" will either be an increase in monetary value of building an item, or an increase in time to delivery. "Costs" in the software domain might be -

• Cost of hardware or hosting monthly fee(s)
• Increase in time to develop or deploy
• Compensating technology required for security, or risk mitigation

This isn't a complete list, but its a good start. Our ultimate goal is to define a set of "Weighted Factors" that we will use to score a particular design option. But first, lets explore the different types of Design Options, and explore a few examples in the Software engineering domain.

Key Point: Each factor varies in how linearly it will effect the "cost" value. Higher costs are bad, lower costs are good. Costs will be normalized by the weighting scale applied to each factor to ensure one factor doesn't overly control the outcome.

Types of Factors

Binary Decision Factors

Binary factors are those constraints that are an absolute Go or No-Go. Any factor that will clearly eliminate an option should be the first criteria analyzed. If a certain criteria is met (or not met), the highest cost should be assumed - ensuring that this option can never be chosen (not without due negotiation anyway!)

Tipping Point Factors

Some factors have no "cost" impact until they pass a certain threshold. An example might be disk space use. Until your product passes the requirement to need more than 100MB of disk space, there is no cost; After that you pay a premium. These factors need to place the lowest cost on a factor, once the tipping point is reached, the factor must assume the highest cost ensuring this option cannot be chosen, otherwise this factor should be zero and not impact the rest of the decision tree.

Scaled Factors

These are general quantifiable factors. The offer a mechanism to determine (and indicate) how a factor impacts cost. E.g. Adding an extra business service layer will increase the deployment complexity and may need extra servers. We'll discuss how to formulate a scale for these factors in a future article, but in this example you can imagine that adding servers has a cost, and each extra architectural layer increases the cost accordingly.

Determining the Relevant Factors

This is the crux of the story. We need to identify the factors that we will score. There is no master list of factors to draw upon. It is important that each factor fall into a category listed above - Binary, Tipping Point or Scaled.

The basic process is to get all the stakeholders into a room and extract (brainstorm) factors that will in their opinion cause an extra cost. No factor is too small at this stage (we'll filter them later), just keep the crowd focused on identifying issues that can increase/decrease effort, cost, time and risk.

By then end of a session you should have a stack of post-it notes littering a whiteboard. Use post-it notes so that you can join and link duplicate concepts and ideas. If you involve the right people, you should end up with a big list of factors. How many are too many? Impossible to quantify, but once a list of Factors is defined, the weighting process should spotlight those factors that fall below a level that will alter any outcome. These factors can then be dropped.

I've not got a complete list, or even a recommended list at the moment. Hopefully sometime in the future I'll have something more, but for the fact of this article, here are a few I jotted down in three minutes (some overlap, some are duplicate, some can't be measured, and some don't make sense at all - all problems to look at later)-

• Bandwidth utilization
• Disk space required
• Number of Architectural Layers
• Database size
• Number of Database Objects
• Number of different development languages
• Number of different technologies
• Number of integration points
• Number of external partners integration points
• Number of config settings, and ease of changing
• Production event logging, how much, to where, how often?
• Ease of deployment
• Number of Servers
• Number of third party components
• Ease we could host at a co-located facility

In future articles, we'll look at how to take this list and refine it down to a manageable set, and how we would scale and weight each factor.

Troy.

In electronics design, many elements can directly impact the cost of manufacturing a product. DfM aimed to move the tradeoff analysis for decisions affecting manufacturing as early as possible in a design phase. I'll attempt to move this into the software architecture realm in a future article, but for now I want to explain how this worked in Electronic Product design.

What design decision matter in Electronics?

In electronic product design, here are a few to start your thought process -

Component Selection - Choosing components from an approved supplier and components that meet requirements but don't exceed specification (giving latitude to safety margins) directly impact cost of an item. Assisting engineers choose preferred part, parts already purchased and in inventory, and offering alternatives can really decrease costs and improve turnaround time.

Printed Circuit Board Size and Shape - Small PCB's aren't made one at a time. They are panelized onto larger sheets, fabricated and even assembled (components positioned and soldered into place) in that form before being broken apart and put into their cases. The more individual boards you can fit to a panel, the less waste and fewer panels need to be moved through auto-assembly equipment.

Printed Circuit Board Technology - If you make the board smaller to fit a certain device, you often need to add 'layers' for interconnecting components. This adds cost; If you make individual features smaller to fit more interconnects onto fewer layers, the manufacturing yield decreases due to mis-registrations. Its a real trade-off and highly dependent on your partners capabilities.

Printed Circuit Board Hole Count and Sizes - For some PCB technologies, drilling holes can be time consuming. Smaller holes needs to be positioned more accurately and these drill bits break more often. Normally, fewer holes of larger sizes is the cheapest way to go; However, some PCB technologies don't incur a cost per hole - which one will you specify?

Component Placement - Where is it safe to put large components? Where will the battery connect? Where are the pushbuttons? All of these decisions need to be considered when the PCB is being designed - BUT they seriously impact the final case design. How can the electronics designers and the mechanical (and brand) designers collaborate to agree on an acceptable design? For extremely high volume designs, placing similar components in the same orientation can reduce the number of machine rotations and component reel changes which reduces the total time of assembly. Saving 1 minute for 1 million pieces is substantial!

Early Focus and Scoring Matrix Definition

Design for Manufacture initiatives aimed to bring focus on the types of decisions made above and allow engineers and designers to perform trade-off analysis as early as possible in the process. The product might have to be smaller than a competitors and that forces a smaller PCB size and shape, which then causes a specific choice of technology - However, the key aim was to understand that early and make informed choices about which remaining options fulfill the global good.

To build a Report Card or Scoring Matrix, the basic process is -

1. Get together with all of your partners, suppliers, fabricators and designers and brainstorm a set of issues that impact cost. Similar to the list provided above, the idea is to get the 'issues list' on the table.
2. Group these issues into a sub-set that can actually be measured and scored. E.g. "Number of boards per panel", "Number of holes smaller than 0.5mm", "Number of different components types", etc.
3. Determine relative weighting for each measurement. Some requirements cannot be broken, other just incur a cost. I'll propose a process for determining this weighting in a future article; for now, just understand they won't all have the same weighting factor.
4. Build the scoring scale for each factor. This step tries to normalize the different scales of measurements into a smaller linear set (i.e. 1 to 5, rather than 1 to 1 million for one factor, and 1 to 10 for another)
5. Calibrate the scorecard by testing on existing systems. Agree and alter the specific factor "Weightings" until you gain confidence in the scorecard
6. Use the scorecard on future design discussions.

Summary

Is it just as simple as substituting "IT Operations" for "Fabricators"; "Usability/Interactive Designers" for "Packaging Designers"; "External Hosting Partners" for "Suppliers"? 

In future articles i'll look deeper into -

• How to build a weighted score card based on issues relevant to software
• Propose some software specific issues and attempt to weight those appropriately
• Test our new scorecard and determine if it is achieving the goal we intended.

Be interested in comments as to whether other people agree there might by parity between DfM in Electronics to DfM in Software.

Troy.

I started out in the electronics engineering field, and moved into the software side of electronics design automation business shortly after that. Back in the early 1990's a lot of effort was being put into Design for Manufacturing. This was in the recognition that very small decisions made early by an isolated engineer, could have massive consequences down the road impacting costs. There were a few leaders and advocates in the field, mainly from HP and IBM at the time.

One incident recalled by Happy Holder, a HP engineer at that time was the reduction in cost of the HP Laserjet III printers. By altering the size of the main printed circuit board size by a few inches one way, they were able to double the production yield of that assembly, halving the raw material cost of the PCB. Happy Holden and IBM's Tucker Garrison at the time came up with a few simple methods for evaluating designs and allocating a report card. The most complex part of the process was getting the right people in the room to agree on the right criteria to measure, and to weight those measurements in the right way.

Manufacturing optimization comes down to improving production yield (reducing waste) and speeding up the process (reducing touch time); These principles are well known to all those proponents of Lean Manufacturing and Theory of Constraints. This book is a good start - Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (The Coad Series).

Is software yield (throughput) equivalent to DFM for Electronics "Speeding up the process"? The aforementioned books clearly describes the process of improving throughput by reducing the waste and understanding the current blocking issues. But I cannot find a process that brings focus of the cost of decisions back to the earliest possible decision point, when it is relatively simple to move many directions.

It seems obvious there is room for innovation here. Provide a framework (what DFM calls report cards) that developers and architects can use to assess possible solutions and designs for a requirement. I plan over the next few weeks to explain how the Electronics DFM process worked, and suggest a few techniques that might improve our up-front decision making process.

Troy.

Due to the amount of spam I was getting (300 odd comments a day) on Community Server - I've decided to move to a simpler blogging engine in the hope I can keep current with new versions, being .NET Blog Engine. Unfortunately, my version of Community Server was so old that I was unable to successfully export the previous posts. I'll move them manually, but it means that this won't happen overnight!

Anyway, bear with me. I promise to restore order as quickly as I can.

Troy.

The company I work hosts a decent size data center to support its business (a website hitting around 1.5Mil hits a day, and countless business applications to keep the company in business). Around the end of last year our backup-power (UPS') and air-conditioning were hitting the alarming 90% level (this is understated!).

The issue wasn't the number of production servers, but rather the pre-production servers for Development, Testing and Staging. Replicating the rather large interconnected complex environment took hundreds of servers, all at 5% CPU utilization most times during the month!

Our Savior: Server virtualization

Just by converting as many pre-production servers to virtual instances and hosting these on decent machines, we saw a reduction to below 45% capacity. The additional benefit is that many of these machines were hosted on poor, unstable hardware previously - virtualized, these are running on solid hardware and in many cases perform better than they did.

If every company house that has software development and testing server resources virtualized their pre-production environments imagine how much less power our server rooms would consume. That has got to be better for the financial operating cost and also better for the environment in general!

Troy.

Consider the scenario: V1.0 is the current application which needs to continue to run without change, and V2.0 is the new application which will alter the existing stored procedure that both V1.0 and V2.0 will be using when released. Both applications use LINQ to SQL to access the stored procedure code.

What Stored Procedure signature changes will cause V1.0 to fail?

Add Parameter – Optional  (OK)

Non-breaking change for V1.0. Since this parameter is not passed in from V1.0, the stored procedure will use the default specified in the stored procedure parameter declaration.

Add Parameter – Mandatory (Breaking)

Breaking change for V1.0 with an exception message “'stored procedure name' expects parameter '@param', which was not supplied.” The workaround is to make this parameter optional by adding a default value to the parameter declaration.

Delete Parameter – Optional (Mostly breaking)

Breaking change for V1.0, except in the case where a Stored Procedure definition for LINQ to SQL has been manually coded to exclude the parameter being deleted (in the V1.0 codebase). In general, all parameters are declared in the LINQ to SQL C#, or VB code to call a Stored Procedure. However, it is possible to declare your own method definition that chooses to exclude one or more optional parameters.

Delete Parameter – Mandatory (Breaking)

Breaking change for V1.0. No workaround. The parameter can be ignored in the new implementation of the stored procedure, but the declaration needs to remain in place until all versions who pass that parameter are deprecated.

Increase Parameter Size/Scale (OK)

Non-breaking change for V1.0. If V1.0 encountered errors due to the parameter size being too small, these will be corrected by increasing the parameter size.

Decrease Parameter Size/Scale (Mostly OK)

The parameter data is truncated if it exceeds the size of a declared parameter. This will not cause an error during Stored Procedure execution, but it might cause a functional error in the application. A change of this type should be carefully analyzed.

Add Default to Existing Parameter (OK)

Non-breaking change for V1.0.

Remove Default from Existing Parameter (Mostly OK)

Non-Breaking change for V1.0, except in the case where a manual Stored Procedure declaration has been made omitting an optional parameter. All LINQ to SQL definitions for the Stored Procedure and callers should be examined to ensure they pass the parameter dropping the default.

Reorder Parameters (OK)

Non-breaking change for V1.0. Parameters are accessed via their names. However, other applications might set parameters by index position, and these will fail.

Rename Parameter (Breaking)

Breaking change for V1.0. A renamed parameter is seen as a deletion of the current parameter and the addition of a new parameter.

Troy.