掲題、
制約を有効にできませんでした。行に入力できるのは、Null 以外の値、一意な値、あるいは外部キーですが、この制約の違反が 1 つ以上の行で発生しています。
Wiggle原因は、TableAdapter（データセット）絡み。ただのテーブル読み込みFill（Getdata）でエラーが出る。
私の場合、TableAdapterを作った後で、あるテーブルの文字（char）桁数を変更したため、データセット上の静的な型情報と、リアルテーブルの情報とが合わない。そのため実行時にエラーとなり変に和訳されたメッセージ出力された。要するにデータセットとリアルテーブルが合致していないため。
よくある？事ですね。
VSのデータセット上にある型指定されたテーブルスキーマーは堅物、一度作ってしまうとテーブル変更に対応出来ず、恐ろしい問題を起こすことがあります。
・・クリスタルレポートはテーブルの変更時、手動クリック一発！で、保有スキーマの自動修正（最新化）を行ってくれるのに、なんでTableAdapterは出来ないんでしょ？
解決には、現在のテーブル構造とVS上の静的な型情報を突合せ、問題箇所を見つけるしかないです。集団開発であれば、体制がしっかりしていない、もしくは開発進行レベルの低い現場で多発しそうな問題ですね。
（余談）
この.net仕様に含まれない、作成するとソースコードが自動生成されるTableAdapterですが、マスターメンテなどデータソースからドラッグ＆ドロップするだけでプログラムが瞬時に1秒で完成してしまう。画面1枚1秒！、と言う恐ろしく楽な代物ですが、過去の怖い面の話。
プロジェクト内部のフォームやその他に対してイレギュラーな操作を行った場合、恐ろしい結果を引き起こすことが稀にあります。
私の場合、結果的にプロジェクトが壊れソリューションから作り直しました。
原因はTableAdapter使ってマスタメンテ作った後にSQLサーバー上のテーブルをいじった。上記の些細なメーッセージを発生させた原因と同じですね。
結果あるはずの項目がなくなり、ないはずの項目が追加され、桁数やデータ型が変更になった結果、フォームを開くと例の赤×のエラー画面が現れ、フォームが壊れた。
全てのマスターメンテフォームが壊れている（壊した）ことが発覚し、当該フォームを全て削除したがエラーが取れず、最終的にプロジェクトが壊れたと判断し、そのソリューション自体を捨て、新たなソリューションを作り直した。
どうもこのVSのウィザードは昔から信用できない。と言うか、.netﾊﾞｲﾅﾘーは大変素晴らしですが、VSが自分で自動生成したソースと、その自動生成されたソースを変更するためのVSの内部コードが怖い。上記フォームが壊れ始めた時に内部バグがプロジェクトを壊した気がする。あくまで想像ですが。
でもこんな簡単に酷い状況になったのはVS2010が初めて。フォームの画面があの赤×になったのは初期の.net2.0以来10年振り？軽微なのは以前のVSにもありましたが、慎重に進めた方が良いです。
ただそうなった原因はどうでも良く（私はMSの人間でないから）、とにかくこちらの開発を止めない対応が必要で、それは・・・
私はTableAdapter絡みで何か修正を行う時は、それがたった1行の場合でもソリューションフォルダ自体のバックアップを行います。何か問題が起きればすぐリストア。
Ctrl＋C、Ctrl＋V、とわずか0.5秒で終わる事をやらなかった為に・・・
ただソース管理入れてる人はどうするのでしょうね？チーム開発してる人。
簡単にリストア出来るのかな？自分のｺｰﾄﾞならそのコードのみリストアすれば良いけど、TableAdapter等のMSが生成・変更したプログラムが何処まで広がってるか？影響してるのか？そんな事分かるのかな・・・？
_
