It could be good if warnings could be turned off - per warning. Example: I have some warnings (circular reference, IsNullable is set to true while IsOptional=false) which are by design and thus I'd like them to disappear from warnings pane. At the same time I'd like to see new warnings if any.

That won't be happening, I'm afraid. The warnings are always generated and always visible, because the project might be transferred to another person, who might not know the warnings are hidden and will overlook them. Every warning is something one should seriously look into fixing. The only warnings which are changeable are the ones generated for unmapped target elements.

I tend to disagree. You are right in overall but there are exceptions to the rule.

Lets say I have a master table and a detail. Master table holds a reference to a single preferred detail (i.e. current detail), like:

Master

Id, CurrentDetailId ...

Detail

Id MasterId, ...

There you have it, a circular reference which is benign in my case or am I missing something? Since I can't hide this warning I simply can't get to 0 warnings and now I am getting used to warnings and perhaps I might miss a real one.

that warning is not something to 'ignore', it's given for a reason: you should actually try to remodel your model: in your case, add a 3rd entity which models (one side of) the cyclic relationship, i.e. 'ActiveCurrentDetail' which contains MasterId and CurrentDetailId. The reason is simple: it will likely make it impossible to insert the rows in 1 go in your setup, so the warning will warn you up front that this will likely happen at runtime (it doesn't have to, i.e. when you set 'CurrentDetailId' after the fact and a null/0 is acceptable in that field).

So hiding that warning will make you forget it's there, e.g. within a year or so, you make the CurrentDetailId field non-nullable, and suddenly things start to fail, but you wonder why. Then you have to remember you hid a warning.

I can understand the reasoning, however it doesn't apply in my case. Now I have to do the heavy work creating another table to get rid of the warning.

Here is another example. I have a sql server view with a column defined as CAST(1 AS BIT). For some reason sql server reports that as "bit, null" and not "bit, not null" and right now I am not seeing how to make it not null. But the field is non nullable and actually a read-only of course. Yet, I can't get rid of the designer's warning. Any idea how to solve this one?

mihies wrote:

I can understand the reasoning, however it doesn't apply in my case. Now I have to do the heavy work creating another table to get rid of the warning.

Just go ahead and create that table, you'll be forever grateful .

About the view: That's indeed a tricky one. I think it's because CAST can return null. It doesn't interpret the code/data cast at compile time (as SQL is an interpreted language). Could you try: COALESCE(CAST(1 AS bit), 1) ? Not sure if that will work though. You could also return 1 as constant in the view?

Haha about that table.

About the view. Nope, COALESCE doesn't help (a matter of fact it produces "int,null").

I guess I could return an int but then I'd have an int instead of bit. I can map that to a boolean in Designer, right? That's one way to solve it I guess, the only drawback is that the view will now describe the column as an int instead of a bit.

BLOODY SQL SERVER FOR NOT HAVING TRUE AND FALSE keywords. THAT. AND ARRAYS.

Check this out: http://stackoverflow.com/questions/6627908/sql-server-2008-convert-statement-in-view-makes-the-data-type-null-in-column-def

Hey Walaa,

That did the trick. Though I think I tried IsNull before but obviously I did something wrong.

Great, now I have to create that table and even worse, include a bunch of IsNull-s into view definitions. So much work...

Otis wrote:

that warning is not something to 'ignore', it's given for a reason: you should actually try to remodel your model:

Sometimes a warning just doesn't apply to your situation.

I have loads of warnings saying 'the relationship x.x has one navigator which is empty, which could lead to problems with SelfServicing', in this case it would be nice to hide them because hell would have to freeze over before I start using SelfServicing

Now it just prevents me from immediately noticing warnings that do apply to my project and I shouldn't ignore.

Warnings which are not meant for you are something else than warnings you think are not important, IMHO. You do bring up a good point.

One can then abuse that system by ignoring warnings one shouldn't hide, but alas...

We'll consider it in a future version. It's not that easy to do today as our warnings don't have numbers, so we have to centralize them and update the messaging system we have in the designer.

In 4.2 warnings have an ID and can be 'ignored', by using a button in the error list. This will mark them 'ignored' (or un ignored), and you can hide / show ignored warnings by clicking another button. This way you can still get the warnings if you want to, and hide them if you don't want to. The IDs ignored are saved in the project file.

This should solve this terrible burden for everyone, I think

A small code addition for Frans, a huge step for LLBLGenPro-ers.

Otis wrote:

In 4.2 warnings have an ID and can be 'ignored', by using a button in the error list. This will mark them 'ignored' (or un ignored), and you can hide / show ignored warnings by clicking another button. This way you can still get the warnings if you want to, and hide them if you don't want to. The IDs ignored are saved in the project file.

This should solve this terrible burden for everyone, I think

Great! Now I still just need to upgrade to 4