I really wonder why I typed all the replies if they aren't read anyway, as you seem to repeat yourself again with the same questions I answered already. You also don't have to re-state that the change is less ideal, as I already said I can understand you're upset and don't like it.

I don't mind debates with customers over features we add or changes we make. But if adding new features means I have to take flak from customers because they don't like changes, I have to re-consider adding new features or have to consider a more MS' like response system, where we answer questions with limited answers and close threads like this with 'by design' and no further comments.

If I say I don't like your tone, it's not just a remark, I really don't like your tone about this and if you want to keep pushing that, I will eventually have to halt it. We're a small team, we spend a lot of effort in helping everyone out here and spend everything we can to build the best designer out there. We sometimes have to make tough decisions and not everyone will like them, like I've illustrated above as well. We learned years ago already that you can't please everyone, so even though we will try to make everyone happy, we know we won't succeed in that. That sucks, but that's part of the job. However if someone, who apparently isn't happy, makes life difficult for us on our own forums, we draw a line.

So in other words, be constructive from now on. And that's not a question.

JayBee wrote:

IMHO happyfirst has every reason to be angry. I dislike this feature too and am not looking forward to converting existing applications from 2.6 to 3.0. For now I have decided to develop new apps in 3.0 and maintain the older ones in 2.6.

For the gazillionth time, we know it's not ideal. The other options weren't ideal either. We do have a feature request on the roll for 3.1 where ordering will be added and we'll look into adding something to that to make it easier for people who want to pursue this route. But don't kid yourself: in the end it will be problematic in other ways, as v2.6's ordering wasn't ideal either, especially in multi-db projects (where it downright sucked, and much much harder than happyfirst or you have experienced) or in situations when a DBA changed an ordering and didn't tell the developers.

yes, not situations you're in, so who gives a ****, right? Well, these people are our customers too and also rely on us to solve it.

Customer is king! I do not like the tone of the replies to happyfirst postings.

If we do our best to 1) solve a problem and 2) to explain it to you all, what else can we do, besides do what you tell us and screw over other people who also are our customers? Aren't those customers 'king' as well? Or just the people who are vocal on our forums?

You only see your own situation, which isn't ideal, as I've explained above a lot of times. Other people's situations isn't ideal either so we tried to solve all in a way that is 1) correct on the entity model level and 2) gives predictable code always (no matter what the ordering is of the fields, the fields are always ordered based on the same scheme, i.e. predictable). So less problems in the future and more features, for all of you.

What I don't like is endless ranting even after I've explained why we did it, that there are others who have different problems and not a single solution fits all these problems so we had to make choices.

And you might not like the 'tone' of my replies, but frankly, I'm beyond the point that I really care about that at the moment. Like I said above, we also could cut the direct lines with the dev team and answer questions on a more MS way, not give you background info and simply close threads with posts like this. Would that be better? No of course it wouldn't.

For people who hate to read long texts and / or got infuriated with the 2 posts above, the low down of what we will do in 3.1:

• as some people have requested ordering of fields since the last phase of the beta, we will add custom field ordering in entities. This was already planned
• by default the ordering of pk fields and UC fields in code will be alphabetical. This will be the default and recommended choice.
• we'll add a setting where you can opt for using the custom field ordering for PK/UC field ordering in code. (this is newly added to the workitem)
• we'll add a setting where when reverse engineering is used, the ordinal order is the default custom ordering. (this is newly added to the workitem)

Refreshing with a different ordinal order will NOT update a custom order, neither will multi-db usage where you switch db's for example, it won't update custom ordering.

The two additions to the workitem will make v3.1 getting delayed a bit, how much is unclear.

Otis wrote:

• by default the ordering of pk fields and UC fields in code will be alphabetical. This will be the default and recommended choice.
• we'll add a setting where you can opt for using the custom field ordering for PK/UC field ordering in code. (this is newly added to the workitem)
• we'll add a setting where when reverse engineering is used, the ordinal order is the default custom ordering. (this is newly added to the workitem)

Refreshing with a different ordinal order will NOT update a custom order, neither will multi-db usage where you switch db's for example, it won't update custom ordering.

The two additions to the workitem will make v3.1 getting delayed a bit, how much is unclear.

Thank you very much. The newly added items are really appreciated.

One more question, not a rant, will/could there be some provision/setting so that optionally projects could have their custom internal order overwritten with the ordinal order when refreshing from the db? If so, then we could stay on 3.0.

happyfirst wrote:

Otis wrote:

• by default the ordering of pk fields and UC fields in code will be alphabetical. This will be the default and recommended choice.
• we'll add a setting where you can opt for using the custom field ordering for PK/UC field ordering in code. (this is newly added to the workitem)
• we'll add a setting where when reverse engineering is used, the ordinal order is the default custom ordering. (this is newly added to the workitem)

Refreshing with a different ordinal order will NOT update a custom order, neither will multi-db usage where you switch db's for example, it won't update custom ordering.

The two additions to the workitem will make v3.1 getting delayed a bit, how much is unclear.

Thank you very much. The newly added items are really appreciated.

One more question, not a rant, will/could there be some provision/setting so that optionally projects could have their custom internal order overwritten with the ordinal order when refreshing from the db? If so, then we could stay on 3.0.

You do realize you'll be back at square one with that setting, right? Imagine: Table Foo (b* (int), x* (int), a (int))

now, a is made part of the PK and x is removed from the pk, and order is altered Table Foo (a* (int), b* (int), x (int))

this creates in the code a breaking change but you don't know it: it's equal to what you run into now. Not that common but it is a problem you could face again, unwillingly.

The setting you propose is also not ideal for multiple db projects: they can't be refreshed at once, so the db refreshed later (which is arbitrary, it depends on the user) dictates the ordering.

I.o.w.: it's best to keep the ordering at the entity level separated from the table level, so use a custom ordering if the alphabetical one doesn't feel logical to you, but keep that ordering, to make sure code generated looks the same after a refresh.

What would this setting you propose solve for you?

Otis wrote:

You do realize you'll be back at square one with that setting, right? Imagine: Table Foo (b* (int), x* (int), a (int))

now, a is made part of the PK and x is removed from the pk, and order is altered Table Foo (a* (int), b* (int), x (int))

this creates in the code a breaking change but you don't know it: it's equal to what you run into now. Not that common but it is a problem you could face again, unwillingly.

The setting you propose is also not ideal for multiple db projects: they can't be refreshed at once, so the db refreshed later (which is arbitrary, it depends on the user) dictates the ordering.

I.o.w.: it's best to keep the ordering at the entity level separated from the table level, so use a custom ordering if the alphabetical one doesn't feel logical to you, but keep that ordering, to make sure code generated looks the same after a refresh.

What would this setting you propose solve for you?

The desire is to get the generated code back to the order it use to be in. So no matter what, code is going to need to get fixed again. I'm prepared for that. But how that order gets restored in the designer is the issue. Manually, entity by entity using some new designer feature, or just refresh the ordinal order back in from the db with a setting turned on?

Also, in your example, you're combining two things, CHANGING the primary key fields and also reordering. BTW, in your example, isn't there still a problem even with 3.0 today? Wouldn't the code still compile but possibly be in error? Is that the kind of change a dba would make without communicating at all to the developers? Before you generate a method with int x, now it's int a, code still compiles, but developer is passing in the wrong data now?

What about an example where somebody renames part of a multi primary key (all ints) but keeps the same order. With 2.6, wouldn't everything have just kept working but with 3.0, there's the "possibility" of a breaking change that wouldn't automatically be found depending on the new alpha order? Regardless, that's not your fault, it's ours?

And the primary key order very rarely if ever changes so generated code would be fine even if I kept accepting ordinal order overwrites. Chances are if the primary key is changing, I'm the one doing it and code will be fixed up. And if not, the change would be getting communicated to developers.

Maybe I'd probably would only use that optional setting once, the first time I refreshed with 3.1 to get back to what I had with 2.6. Then it would just stay off after that. Or maybe I'd leave it on? I'm just so use to seeing the fields in one order and knowing that order and quickly finding fields. Now I'm having to search around and do mental alphabetical thought checks to try and quickly find where a field is instead of just relying on habit and knowing where in the list it was.

My understanding is that if somebody were to leave the setting on to always overwrite with ordinal order, then it would basically be back exactly to what we had in 2.6. And if I change the multi primary key ordinal order and it breaks code, well, that's MY fault. Same as it would have been in 2.6. Is this right?

Frans,

Although I'm not happy with the current order, I accepted it after the answer of David.

I too have to deal with PK's such as orderNumber, linenumber. I have worked with several DBMS and I cannot recall having to deal with PK's in which I (or a DBA ) could not determine the order of the fields in the PK. I'm happy that some kind of solution will be made available in 3.1.

Reading some of your answers gave me the impression that you were losing your temper while typing them in. One should stay polite when reacting to a customer complaint, regardless of the complaint itself. He's the one with the problem.

So in other words, be constructive from now on. And that's not a question.

I fully agree

Jan

JayBee wrote:

Frans,

Although I'm not happy with the current order, I accepted it after the answer of David.

I too have to deal with PK's such as orderNumber, linenumber. I have worked with several DBMS and I cannot recall having to deal with PK's in which I (or a DBA ) could not determine the order of the fields in the PK. I'm happy that some kind of solution will be made available in 3.1.

Reading some of your answers gave me the impression that you were losing your temper while typing them in. One should stay polite when reacting to a customer complaint, regardless of the complaint itself. He's the one with the problem.

If I'd lost my temper, you wouldn't be able to post on this forum anymore.

The point is that I don't tolerate endless ranting when we honestly did everything we could and explained a couple of times why, what the alternatives are etc. If that doesnt stop, I'm not in control anymore over the conversations here and that's not what will happen. Not because I don't like ranting, but because it is just a waste of time.

@happyfirst: I get back to you tomorrow

@happyfirst

You have a point where you say that to get the initial state back to what you want (ordinal based ordering), it would require a lot of manual labor, so a setting which is usable to get that state but likely will be 'off' for the majority of cases is indeed preferable. It will allow people to shoot themselves in the foot, but a user isn't a baby.

We'll add that setting too, if it's technically doable.

Otis wrote:

@happyfirst

You have a point where you say that to get the initial state back to what you want (ordinal based ordering), it would require a lot of manual labor, so a setting which is usable to get that state but likely will be 'off' for the majority of cases is indeed preferable. It will allow people to shoot themselves in the foot, but a user isn't a baby.

We'll add that setting too, if it's technically doable.

Thank You!!

Implemented for 3.1.

You can manually set field order in the designer in an easy dialog which can be used with the keyboard and which is accessable through project explorer, model view and entity editor.

There are two settings added. One for syncing field order with target table/view and one to set field order for new elements. This is used for both reverse engineering a new entity / typedview from target (table / view) or when working model first: the order in which you specify fields is becomes the fieldorder. Both are off by default.

Field order is also used to determine the order of fields in new tables when working model first. Field order is not used to re-order fields in existing tables, as there's no DDL SQL statement to re-order columns in a db table.

Field order is used to set field ordering in value types when refactoring and bouncing back (valuetypes are not supported on our own framework btw), used to order parameters in spcall's in the designer (code generation is still using parameter ordinal of target).

For code generation, the field ordering set is overruling the alphabetical ordering, so fields are sorted on FieldIndex ascending, Name ascending. If there's no field ordering set, the fields are automatically sorted alphabetical. You can set ordering per-entity.

It has only an impact on our own framework mostly, and the v1-style static factory method for entity framework. NHibernate and Linq to sql are not affected by any field ordering, as they don't have the notion of field order, neither does the entity framework btw (only in that single static method).

It took a while, but it's now fully build in and should suit your needs. V2.x conversion template will of course take into account field ordering and will emit a project which has field ordering set by default, to make migration of code to v3 from v2 easier.

Awesome! It's really appreciated.

Thanks again!