Dynamics-NAV 5.0 vs. 5.1

Scott_Frappier · 2006-12-09

Hello Everyone:

I hope that everyone’s upcoming holiday season will be relaxing. Here in the U.S. everyone that I have talked with is ramping up because of year-end and preparing for the W2 (taxes) processes. We've been busy; as I'm sure all of you have been as well

.

I wanted to start a thread that gave factual information regarding Dynamics-NAV 5.0 vs. 5.1. Everyone here has always been very gracious to me and helped out when I was posting at the beginning of my career 5 years ago, and since then, a lot has changed. If any of the information that I have conveyed in this thread is not accurate, please feel free to post!

We (Symbiant) have been involved in a couple of meetings with Microsoft personnel at both the Worldwide Partner Conference earlier this year, and at the Dynamics-NAV "Directions" event that occurred recently. The information that we have come across has helped with our company planning/vision, and it seems that some may not know of the specific direction that Microsoft is taking the Dynamics-NAV product. So...let's dive into the details.

Dynamics-NAV 5.0
At Directions, Mogens Elsberg announced that the 5.x clients will be coming in two phases. The first phase will occur in H1 2007 with the release of the Dynamics-NAV 5.0 client. This client is in fact, still a two-tier design. Based upon all of the correspondence that we had encountered before the Directions event, it was stated the 5.0 would be a 3-tier environment. This is _not_ the case with the 5.0 client.

The 5.0 client will be basically a functionality upgrade. The C/AL code has been enhanced (feature add's) to help compete with the existing markets. Some of the new big features are a kitting system and a basic workflow engine for notifications (similar to a PO approval process). On top of this, the 5.0 client can now export anything that a user can see to Excel or Word. With the export functionality, VAR's can develop specific CSS (Cascading Style Sheets) to format the layout of a form to Word. One of the really neat presentations that has been made is taking a Sales Order and exporting it to Word. Since you can use all of the formatting attributes of Word, the document looks very clean and sharp, and can be modified to each of your customer’s individual tastes.

While adding anything to the product is definitely helpful to the Dynamics-NAV community, there was a sense of disappointment because of the sudden change. It was then announced that 5.1 would be the official release of the 3-tier environment, and will arrive sometime in H2 of 2007.

Dynamics-NAV 5.0 is available for beta testing if you meet some of the requirements that have been set by Microsoft. There was a 3-day training session in Copenhagen during the EMEA Convergence in which NSC's were allowed to get a hold of the Dynamics-NAV 5.0 client. We did not attend because of other commitments, but from what I have heard, it was an event that quite a bit of NSC's in the U.S. market attended. The individuals that did attend this event did not receive (to my knowledge) the new 5.1 client, as it is technically still in an architectural design phase (this is what has been conveyed to us).

Dynamics-NAV 5.1
Dynamics-NAV 5.1 will be the first product that will offer the new 3-tier environment. A new client will be developed that is the presentation/gui layer, and the business logic is handled on the IIS layer. The last tier, or RDBMS, is handled by SQL Server 2005. I have had the following communicated to me by Microsoft personnel:

* There is brand new GUI environment that is visually appealing. Some of the look and feel is similar to AX (instead of tabs you have those drill-open forms), but it still retains the ease and practicality that we have loved about Dynamics-NAV in the past. * 3 new object types will be introduced. A new form (page?), new report, and a web service object are the known objects. * The new form works on the Dynamics-NAV 5.1 client. You must convert your forms to the 5.1 design. * There will be conversion tools available that will convert the old-style forms to the new ones. Matrix-box forms will not be supported with the "automatic conversion". * The report engine uses a technology _based_ on SQL Server 2005 Reporting Services. It is called the ReportViewer (http://www.microsoft.com/downloads/details.aspx?familyid=8a166cac-758d-45c8-b637-dd7726e61367&displaylang=en)

* The new client is _not_ being touted as a thin client. The data that is transferred from the business logic to the presentation layer is basically XML. It still sends the full record set data to the client.

* The ReportViewer technology does not run on the server like SQL Server 2005 reporting services does...it is a client application. It must download all of the data and then transform it to the new format using the RDL format that is created with the new report builder.

* There will be a new form builder as well. Forms are no longer WYSIWYG...they are tree-based. This allows developers to create forms that are dynamic based upon user’s permissions (i.e. potentially field-level security).

* Since forms are not in a WYSIWYG environment, developers will not have control on where they appear to the user. They can "group" controls, but they cannot explicitly state where it will show on the form.

* Some triggers on the old C/AL forms will not be compatible with the new forms (I do not know the list).

* There will be three steps for the creation of an object. The first is to develop, the second is to compile, and the third is to deploy. The deployment uploads the object to the IIS server as a managed .NET assembly.

* The .NET assemblies on the IIS server cannot be edited by an NSC.

* The C/AL code is translated to C# for the managed assemblies.

* In order to deploy an object, you must compile the _entire_ database. There was a lot of push-back on this at the meetings I have participated in...Hopefully it will change by beta/release cycles.

* The 3-tier design does not load-balance across multiple servers. If you have two IIS servers running, you must point half of your user-base to one server, and the other half to the other IIS server.

* The 5.1 development will still occur in a C/AL client (i.e. 4.0, 5.0). There is no snap-in to Visual Studio...we will still be using the same tools that we have used in the past.

* Documentation (manuals) will be available as PDF's (hooray) for customers on the enhancement plan.

* The product is still not considered a web application. As I stated before, it is not a thin client, but it is the first step in creating an architecture that allows multiple UI's for the business logic.

* Web services will be hosted on the IIS server. Web services can drive business logic within the Dynamics-NAV 5.1 environment. We are planning on using this technology with our nTier Architecture Services (an ISV offering that improves the scalability of the Dynamics-NAV system).

As you can see, Microsoft has been very busy building the 5.x applications, and I'm sure that they will not disappoint. As with anything, they need to get the product out the door, sooner rather then later. Some of the frustrating things that we will encounter at release will eventually be addressed, but as with any new product launch, there will be bumps in the road.

I am very excited to see what the new platform has to offer (as I'm sure all of you are as well!). As the environment grows, it gives greater capabilities to users, and provides an application that will grow with a business in the future.

Please feel free to add your comments on what you have heard...I do not have all of the answers and I'd love to learn a little more about what will be occurring as 5.x comes to market. I will update this thread with new information as I receive it

.

Thanks again! I hope this answers some of your questions!

DenSter · 2006-12-09

Couldn't sleep Scott?

Couple of things I'd like to add:

The new form works on the Dynamics-NAV 5.1 client. You must convert your forms to the 5.1 design.

You don't have to use the new client. You can still choose to use the 'old' 2 tier architecture. This is for those who want to keep using the NAV database server. If you want to use the new architecture you must convert to SQL Server.

The new client is _not_ being touted as a thin client. The data that is transferred from the business logic to the presentation layer is basically XML. It still sends the full record set data to the client.

Are you quite sure about this? I suspected this, and have asked on a few occasions, but MSFT was non-committal.

The ReportViewer ... <snip> ... It must download all of the data and then transform it to the new format using the RDL format

If this is indeed the case I am very disappointed.... Again they would give us 'new technology' and they take away the very thing that makes that new technology so powerful.... This would completely negate the 3 tier architecture.
I have heard something different though. What I understood was that we'd be designing the data side in NAV, that then would serve as the source for the report, and would reside on the service tier, so that data will not have to travel all the way to the client when reports run. The actual reports would then be designed in the SQL Server reporting tools.

Forms are no longer WYSIWYG

Really :shock: a form designer that is not WYSIWYG? That is very strange. I have a hard time visualizing what this would be like, I would like to see this. I would at least expect something like the web page designer in VS where you have a design view as well as an HTML view.

The C/AL code is translated to C# for the managed assemblies

I'd just want to clarify that we will NOT be able to see the actual C# code. The C/AL code will be translated into C#, but will be assembled into managed code in the same step. There will not be any C# files that we can look at in Visual Studio.

The 3-tier design does not load-balance across multiple servers

Very disappointing... I wonder if that means that it will still be a single thread app....

My 2 cents:
I really cannot wait for 5.1, I think it is a very good step in the right direction. I am just afraid that access to new technology will be severely limited, and we still will not be able to fully take advantage of things like reporting services and better .NET integration. Like so many times before we get access to things (for instance message queuing), but not complete access (no transactional queues, no double byte characters, hardcoded message labels). I understand that they have to consider existing code base, and provide a way to do this inside C/SIDE but at least it should be possible to make that choice going forward. I would like to be able to do all of my reporting in SQL Server reporting services.

Scott_Frappier · 2006-12-09

DenSter:

I was up doing a SQL conversion for one of our clients

. It started at 6:30 PM yesterday and it's almost finished creating keys. Shows that 90 GB C/SIDE databases take awhile to restore to SQL Server 2005

.

No sleep is always fun! :^o

I wanted to follow-up on some of your comments:

You don't have to use the new client. You can still choose to use the 'old' 2 tier architecture. This is for those who want to keep using the NAV database server. If you want to use the new architecture you must convert to SQL Server.

To be honest, I'm not even certain of Microsoft is going to support a C/SIDE 5.1 application. In prior discussions, it was stated that 5.0 (when 5.0 was the new 3-tier architecture) would support one of two modes. The first mode was the "classic" mode which is our current 2-tier architecture today. The second mode was the new mode, which introduced a new client and a new architecture (the 3-tier architecture that we discussed).

During this time, they were also exploring the possibility of doing a "mixed mode", in which 5.0 clients could run in both the C/SIDE and new client environments. They stated that they were "considering it" during our architectural discussions with the development team on Denmark. Personally, I think this would be a great idea as it would mitigate a lot of risk on the solution center side of things. Instead of having everyone move to an unknown technology, it could be done if phases. AP staff first, then order entry, so on and so forth.

As of the 5.1 version, I do not know if they will have a C/SIDE client...I would expect them to do so (we need to develop in this client), but I'm not sure, as MSFT employee's have not stated outright what the vision will be at this time...

You are absolutely correct though, if you want the new architecture you _must_ use SQL Server.

Are you quite sure about this? I suspected this, and have asked on a few occasions, but MSFT was non-committal.

During a discussion at Directions, two or three MSFT employees stated that it is considered a "rich" client, and not a "thin" client. From my development discussions with the Denmark crew at WWPC, I asked if it was a thin client environment and they stated that the data is still sent to the form in full. In some ERP applications, when a request is made to the server for a record set, it will only query for the data that needs to be presented on the screen. If we hide columns, our system does not currently do this, as it is not column intelligent. From what they stated, this will be the same in the new environment.

I have heard something different though. What I understood was that we'd be designing the data side in NAV, that then would serve as the source for the report, and would reside on the service tier, so that data will not have to travel all the way to the client when reports run. The actual reports would then be designed in the SQL Server reporting tools.

Interesting...this may be a change since the WWPC discussions. At the WWPC discussion, I asked this question very specifically. The answer was that the ReportViewer is a technology that runs on the client application, and not on the service tier. This would then mean that all data needs to be sent to the report viewer so that it will present it to the user. If they have changed this, this is definitely good, but if not, your presentation layer will still technically be doing business logic.

I would at least expect something like the web page designer in VS where you have a design view as well as an HTML view.

I think it was the design view as you stated, and then they had a "preview" mode that would allow you to view the layout, but it is not a drag-and-drop environment where you put a control on the form, and the "What you see is what you get"...this is not the case with the 5.1 design view (tree view is what I recall seeing during our discussions...they actually talked about not doing a preview, and we screamed

).

Very disappointing... I wonder if that means that it will still be a single thread app....

The service tier is a multi-threaded application (thankfully). This is good, as users will not wait for each other at the service tier. The only bad thing is that if one user starts a huge process that requires a lot of business logic processing, he/she could cause an entire system slowdown...which is not good at all.

I would like to be able to do all of my reporting in SQL Server reporting services.

Here here! =D> I agree entirely. As you stated before, it is the first step in the right direction, but at the same time, they will need to support this interim step as well, which in my opinion, would cost more then just doing the right thing, which would have been to integrate with SQL Server 2005 Reporting Services. Technically, it is disappointing to see AX have access to things that NAV cannot...I do not see why this should be the case. NAV is simple, and based upon that simplicity there has been an application designed that is more functional, easy to use, and has a broader market impact the AX. We have a product that contributes the _most revenue_ to the Dynamics division! This is something to be proud of...and also an indicator of where the market is leaning. If you have a product that sells, wouldn't you re-invest into it to make it a better product? Wouldn't you add the new features that you've touted in so many webinar's, et cetera, into the application that has the traction in the market? If Great Plains has SharePoint integration, shouldn't we (more then the Employee Portal, whch is again, a great first step)? If anything else, SQL Server 2005 is such a huge launch, shouldn't we be using some of it's new technologies for our next releases (i.e. Reporting Services) before the competitors?

At the end of the day, I'll take what I can get, but if I were in charge, things would have been different

. *dreaming*

Thanks for your post! Make sure to have a Happy Holiday and a Happy New Year as well!

DenSter · 2006-12-09

<snip> exploring the possibility of doing a "mixed mode" <snip>

I've always understood that it was going to be an 'either/or' situation (either 'classic' or 'new architecture'), not a mixed mode. My information might not be up to date though.

<snip> considered a "rich" client <snip>

Rich client for sure, that's what I always understood it to be. There's a difference between sending out "SELECT *" queries or just the columns that you need though. I always thought it would be the latter, to minimize traffic to the display target. Full record sets sound a bit redundant doesn't it, and weren't they supposed to get rid of those pesky cursors...

At the WWPC discussion, I asked this question very specifically

Alright then... what I was talking about was explained to me definately way before the WWPC this year, so your information would be newer than mine. The way you are describing the report tool just does not make sense to me in light of what MS has been saying. We were going to be using SQL Server reporting tools directly, that was even one of the things recommended for us to start learning. The whole 'data bit on the service tier' and the actual report running on RS does make sense to me. I guess we'll be guessing until we actually see how this will work.

and we screamed

Yeah let's hope we get a preview at least...

It's fun trying to guess what it'll be like, but at the end of the day we won't know for sure until we get the product and can start using it. I really hope that that we won't be limited in what we can do with these integrations (e.g. that we will have a way to fully utilize RS, that we get fullblown webservice capabilities instead of just a little subset, etc.).

Merry Christmas to you too

David_Singleton · 2006-12-10

Hey Scott, nice post =D> :

Scott and Daniel because there are about 30 topics here in one thread I will probably miss some of your comment's and double post, sorry.

Although the community reacted to the WAY the announcement was made, I believe that in general most people accept this as the correct approach. It is very sensible that Microsoft will wait till the product is ready before releasing it. Look at Concorde 3.0 to see what happens if you don't.

AX4 still runs with Tabs like Nav4, the 5.1 ribbons are completely different. Take a look at dell.com (configure a server) to get the idea.

From what I have been told, you will be able to run 2 tier and 3 tier at the same time. This means you can, but don't have to upgrade ALL your forms. It will be possible to move to 5.1, on SQL, and step by step move functionality across. No need to do it all one day. Same with reports.

The forms triggers thing is still a bit up in the air, but the key issue is basically to force developers to put business logic where it belongs, and NOT on the forms.

As to compiling the database, it has been stated over and over and over, that that was just the pre-alpha version, and that there was never any intention of the final release acting this way. I was told at Convergence that the Alpha that demonstrated was just built to show some compiling at Directions. By far this was the biggest miss-understanding in Navision right now.

My current take on the thin client issue (and my understanding on this changes a lot), is that the ultimate intention is for this to be a true thin client, but maybe not in time for 5.1, but that is just my current opinion.

Basically the new form designer will be a MorpX style thing, so its sort of wysiwyg, but not exact, and you don't have the level of control of the detail placement of controls.

As to the future of C/SIDE, firstly we have a 5 year support cycle to think of, so from the time 5.1 comes out (say end 2007), it needs to be supported at least 5 years (2012). At Tech Ed, we were told that NAV 6.0 would be based on C/SIDE, and that 7.0 would probably be based on C/SIDE, so don't throw away your C/SIDE skill just yet.

I would just like to make one comment where I think you have things backwards. Navision is the largest revenue generator for Dynamics right now. This makes it more sensible to push new technology to Axapta and Great Plains. Think about it. The key to Navision's success right now, is it huge installed base, but more importantly its legion of loyal C/SIDE developers. The large majority of these developers (and the consultants, implementors and trainers that they support) did not have any formal computer science training. The large majority came from business backgrounds. This means you have a base of consultants and developers that know business, (and Navision is a business system, not a develops environment). Imagine a person with 20 years accounting experience, and a Navision implementer that was then told "Oh and for the next version of Navision, you need to learn, SQL, IIS, Reporting services C# Visual Studio, Server 2k3, and a list of thirty other technologies.

Yes the customer base can be converted pretty quick, but he value in Navision is that huge base of business trained developers and consultants. And the vast majority are not techies.

ara3n · 2006-12-10

David Singleton wrote:

...
"Oh and for the next version of Navision, you need to learn, SQL, IIS, Reporting services C# Visual Studio, Server 2k3, and a list of thirty other technologies.

Isn't that what we've been told anyways? I would prefer if they just released a new Dynamics ERP and gave everybody upgrade path. Give enough time for NSC to write their vertical or addons for the Dynamics.
The way we are going with 5.0, 6.0 and 7.0, The customer is paying for NSC to upgrade multiple times.

As far as People who don't have technical background, they still function as consultants, and there are many great Consultants that don't know the development but can create great designs or solutions.

As far as loyal developer concerned, we were never on their priority list. Just look at the development environment and issues that have been there for 10 years. For Navision and now MS, business comes first. And you can grab CS students from college and through guidance can have up to speed in the new development environment in no time.

Alex_Chow · 2006-12-12

Yeah, but think of the kind of investments existing solution centers will have to do. Basically they will have to re-train or hire additional staff just to keep up with this. It's basically an reinventation of their existing business.

So much for making a friendly software that can be quickly implemented and customized.

ara3n · 2006-12-12

It will happen eventually. We have to learn all the new features, quirks with 5.1, 6.0, 7.0 and then dynamics. Why not just skip all these versions?
MS did this with .NET. Visual basic was gone. They should do the same with ERP systems, basically give us the new language to use at the same time as using C/Side.
Just like with SQL 2k5. You can still use t-sql, but can develop in .NET as well.

DenSter · 2006-12-12

deadlizard wrote:

Yeah, but think of the kind of investments existing solution centers will have to do. Basically they will have to re-train or hire additional staff just to keep up with this. It's basically an reinventation of their existing business.

So much for making a friendly software that can be quickly implemented and customized.

So now all NAV developers will buy a bok on SQL Server Reporting Services, only to discover that not all features work, and wasting time on finding out the limitations and figuring out workarounds, which is an ENORMOUS waste of time. Rather than forcing it into a limited editor within NAV, I'd like it much better if we could just use all of its capabilities.

So the marketing people can say "NAV is fully integrated", deals get closed as a result, and we're stuck trying to make it work, answering questions on why this or that feature won't work properly.

Miklos_Hollender · 2006-12-12

Some thoughts.

WYSIWYG form design is a good question. On one hand it's very useful for the special cases: touchscreen apps, forms for especially dumb users, or non-ERP-related special things like product configurators. On the other hand this makes it practically impossible to hide fields based on permissions etc. 'cause the form would look horrible after that. Also, it might open up the option of each user configuring the forms to look the way he wants like field order etc. Probably not in 5.1 but sometime. So I'm not sure, there are pros and cons...

Reporting Services. Basically anyone can use RS right now if they want, the problem is FlowFields. If it gets sorted, it could be useful. I checked it out, and right now I'm not very much impressed. It's possible that I did'nt see everything that's possible with it: I just clicked through the usual stuff in the Visual Studio plugin but didn't really found how to export reports to Excel or how to report on Analysis Cubes. Probably these must be possible, I think.

What I'm wondering about that basically Reporting Services is just a skin on SQL queries. I was talking with some SQl enthusiasists about comparing the JOIN-driven reporting of SQL to the procedural reporting of Navision and I think the later one is better. Ther are quite some logic that's hard to express with defining the intersection of sets, be they SQL JOINs or indented DataItems in Navision. In Navision, in this case you can write procedural CurrReport.SHOWOUTPUT logic. It's very useful. As far as I can see Reporting Services has nothing like that - or maybe I just didn't discover it yet.

On learning. I think learning stuff is good fun. And lifelong learning is a natural part of every knowledge-oriented job. But it's better to learn something that's based on wide open standards than some proprietary stuff based on the whim of it's designers. It all too often turns out that the designers forgot about something. It's like writing my first banking interface in Navision three years ago - when we found out that the maximum text var size is 1024 chars and that wasn't enough, and then we rather tried binary mode, and then we found we just cannot make Navision not write binary zeroes to the end of the strings, so we ended up writing an external denullizer.exe and calling it with SHELL... those things are a pain. Who can guarantee Reporting Services can do everything we can do in Navision reports, with the same speed? What if we hit some unforeseen case, some artificial limitation the designers forgot to remove and spend five days on a complex report and then end up dropping it and redoing it in a Navision report instead? Who will pay for that time? Nobody. Such big changes thus always carry quite some risks. I can only hope that the transitition will be smooth to always be able to "downgrade" if something turns really bad.

BlackTiger,

on leaving Navision... you know I was pondering this idea a couple of times. Hacking the Open Source TinyERP system which is written in very elegant and effective Python code would be so much fun. Custom-writing (web) applications in the even more elegant and effective Ruby on Rails would be an even bigger fun. But the problem is sales. Even with all the power of Microsoft marketing and add-ons and whatevers, selling even Navision is hard. (Of course, it matters where. Selling here in England is easier than in Eastern Europe and I've heard ther rumour that selling it in America is very easy, all NSC's are fully booked for half a year ahead.)
And still, selling Navision is the easiest thing compared to selling some other ERP or totally custom developments. True, there are other environments that are more fun to hack. But if you just can't sell enough days to make the rent then it doesn't help much. Maybe I'm a coward but I'm putting job security before job fun. It's very hard to swim against the tide and it's quite clear that Dynamics will soon put everybody else in ERP out of the business (maybe except for SAP R/3 for the really, really big guys). It's such a powerful tide that it's simply easier to swim with it, even if the waves in the water often carry some cr*p at the level of our faces that are hard to avoid and swim around.

kine · 2006-12-12

we just cannot make Navision not write binary zeroes to the end of the strings

- offtopic: what about writing char by char??? :-)

for i:= 1 to STRLEN(MyText) do
  File.WRITE(MyText[i]);

DenSter · 2006-12-12

BlackTiger wrote:

Additional knowledge always is good.

Taking a quote out of context is an art isn't it. :shock: Do you ever try to understand the point someone is making?

I have nothing against having to keep up your knowledge, you should see my library of books. I was making an argument that if we get integration with something like SQL Server reporting services, we should get FULL integration, so we can use all the features, as you would expect when you listen to the MSFT marketing machine.

The way this typically goes is you go 'great finally I can use this' and by the time you start using more advanced features all of a sudden it doesn't work so well anymore.

themave · 2006-12-12

Miklos Hollender wrote:

Some thoughts.

WYSIWYG form design is a good question. On one hand it's very useful for the special cases: touchscreen apps, forms for especially dumb users, or non-ERP-related special things like product configurators. On the other hand this makes it practically impossible to hide fields based on permissions etc. 'cause the form would look horrible after that. Also, it might open up the option of each user configuring the forms to look the way he wants like field order etc. Probably not in 5.1 but sometime. So I'm not sure, there are pros and cons...

From an end user prespective, WYSUWYG forms is a must. Most of our users are not dumb, it is the design of the Navision forms that makes no since from a data entry point of view. Take the sales order. we have had to format it to our way of business because Navision spreads out over multiple tabs info that should be entered on every order.

to fill out the header, we need

customer number
Ship-to code
Salesman Number
Shipping method
shipping agent
Project code

All the rest defaults from the items entered above.

Navision spreads these fields over three separate tabs, and makes no logical since on the way you move from field to field when you hit the enter key. This would be a deal breaker, if we could not make forms look the way we need to streamline data entry.

Alex_Chow · 2006-12-13

There's no problems learning different technologies, other than the money issue. However, it doesn't make sense to take away the very thing that MSFT is marketing heavily, and that is productivity.

It does not make sense to have to force everyone to log out of the system in order for you to make an update to a form; this is not an improvement on productivity from how Navision functions before.

I guess my concerns are really with the performance and the timeframe on how we can implement new clients, it is a huge competitive advantage when selling against other softwares.

However, these arguements are in line with people switching from DOS to Windows. We complained that DOS was a lot faster than Windows, but I guess it's necessary for the continual evolution of the ERP software industry. :roll:

kine · 2006-12-13

The reason why the new pages are not WYSIWYG is, that the pages can be potentially viewed on different devices and the design of the pages is created to support that. It is why you are not saying "this value will be at position x,y and this on A,B". You just say "I want to see info about customer, his orders and blablabla" and it is on the used client application how will present this informations to you. It is why you can create your "own" client (for example for Win CE). Developer is just saying what user needs for his work and client must be able to show this informations in proper and usefull way. And I hope, that the new client will be "intelligent" enough to present the informations in good way... ( [-o< [-o< [-o< )

Miklos_Hollender · 2006-12-13

Themave,

Non-WYSIWYG form design in theory, does not have to prevent streamlining things. It's just telling that this field will be the first, that the second, that third one shouldn't appear at all, etc. , just without telling the exact position or spacing in pixels. Actually in the perfect case it would be configuration, not development, because such information is not too hard to store in a table and read it runtime. In an even more perfect case it'd be set down to individual user level. In an even more perfect case you just set that this user cannot see that field and all the fields below that would "snap up" to it's place, without an ugly hole. So this approach does have it's advantages. Of corse it's just the theory how it COULD be done - f.e. Compiere does it this way - I don't know how it will be implemented actually.

kine · 2006-12-13

I assume (or may be that something more than just assume) that there will be some new properties on the fields to support the new client. To work properly, you will need to mark some fields as "more important" than other (for example customer no., name and city will be more important than his posting group...). And the page will be generated using this informations to show the important fields in preview and all others in detail view... It means, you can set some attributes directly on the table fields and let client to correctly present these values to end user. Yes, you can be afraid of lost of control over that, but if you know some basics from e.g. Axapta, you know, that you can hide group of fields easilly (imagine case, when all cost and price fields are grouped into some group and you can say, that this user is not able to see all fields within that group... voala and you have hidden these fields without changing some visual forms or pages and other, more important fields for that user are visible instead these hidden...) - but, please, take this just as example - I do not assume that it will happen in NAV 5.1 (we can just hope in that...)....

Miklos_Hollender · 2006-12-13

BlackTiger,

hm, let's see if I get this correctly. Say we have 100 000 customers. Say I'm filtering the report for a City that actually has 20 customers. I think what then happens is 1) SQL selects 100 000 customers 2) appserver reads all the 100 000 records and generates a small, handy XML of 100 000 record level nodes and 1.2 million field level nodes. Then it travels from the Navision server to the IIS webserver, then from the IIS webserver to the Reporting Server - which physically, I think, often will be the Navision/database server itself unless you have a really huge and expensive infrastructure, so the aforementioned small, handy XML file is basically making a holiday trip to visit IISland but then it comes right back. Then the Reporting Services parses the XML - XML is famous for being parsed quickly as recursively parsing a tree structure is so much more easier for the processor to do than tossing a pointer through, for example, a fixed-width field file - and finds that 20 nodes that fit the filter criteria and sends it to the user...

Is this working this way?

Granted, it so much more effective than a Navision report or an SQL query into an Excel file

DenSter · 2006-12-13

Could we please not highjack this thread? :shock:

Alex_Chow · 2006-12-13

DenSter wrote:

Could we please not highjack this thread? :shock:

I think it's too late for that...

Miklos_Hollender · 2006-12-14

OK, OK.

Miklos_Hollender · 2006-12-14

Ontopic then: have anybody heard of any planned improvements on how commits/rollbacks are handled? Moving it towards a more structured exception handling-related direction?

The prob is, often you have to do things like f.e. during posting a shipment, go to the order, open it, change the qty, relese it again (this is to allow overdeliveries). Or during the posting of an invoice, create and post a bunch of extra journal lines. Something sort of that. Such changes tend to lead to commit/rollback problems. In the first example, you have to commit after reopening the order, otherwise you'll get a runmodal error sometimes, due to the credit limit warning or something like that. But if you then receive an error for any reason, the orders stay open. So what would be needed is a structured exception handling, something along the lines of open the orders - try { whatever } - catch {whatever} - finally {rerelease them} . Or in the second case, if there is an error in posting your journals stay inserted, because there are commits in the posting process. So what would be needed is, like, create the journal - try {post the invoice} - catch {whatever, and delete the leftover journals}

Any plans about it? Or they just expect us to wrap all such stuff in codeunits?

David_Singleton · 2006-12-14

Miklos Hollender wrote:

Ontopic then: have anybody heard of any planned improvements on how commits/rollbacks are handled? Moving it towards a more structured exception handling-related direction?

The prob is, often you have to do things like f.e. during posting a shipment, go to the order, open it, change the qty, relese it again (this is to allow overdeliveries). Or during the posting of an invoice, create and post a bunch of extra journal lines. Something sort of that. Such changes tend to lead to commit/rollback problems. In the first example, you have to commit after reopening the order, otherwise you'll get a runmodal error sometimes, due to the credit limit warning or something like that. But if you then receive an error for any reason, the orders stay open. So what would be needed is a structured exception handling, something along the lines of open the orders - try { whatever } - catch {whatever} - finally {rerelease them} . Or in the second case, if there is an error in posting your journals stay inserted, because there are commits in the posting process. So what would be needed is, like, create the journal - try {post the invoice} - catch {whatever, and delete the leftover journals}

Any plans about it? Or they just expect us to wrap all such stuff in codeunits?

The answer to that question is fourty two. I think you understand.

Phenno · 2006-12-15

David Singleton wrote:

Miklos Hollender wrote:

Ontopic then: have anybody heard of any planned improvements on how commits/rollbacks are handled? Moving it towards a more structured exception handling-related direction?

Any plans about it? Or they just expect us to wrap all such stuff in codeunits?

The answer to that question is fourty two. I think you understand.

hehhehhhh =D>

DenSter · 2006-12-15

David Singleton wrote:

The answer to that question is fourty two. I think you understand.

:-k huh?

themave · 2006-12-15

DenSter wrote:

David Singleton wrote:

The answer to that question is fourty two. I think you understand.

:-k huh?

Enough of the inside jokes, I come back to the forumn because I get the email that something new has been posted and it is this crap. save it for the breakspace or general chat.

Looking for useful info

done with my rant.

DenSter · 2006-12-15

After I get an answer though

themave · 2006-12-15

DenSter wrote:

After I get an answer though

No problem, I am unsubscribing to the topic

David_Singleton · 2006-12-15

DenSter wrote:

David Singleton wrote:

The answer to that question is fourty two. I think you understand.

:-k huh?

Ask your friend Mr Google the answer to the ultimate question .

Phenno · 2006-12-15

David Singleton wrote:

DenSter wrote:

David Singleton wrote:

The answer to that question is fourty two. I think you understand.

:-k huh?

Ask your friend Mr Google the answer to the ultimate question .

Or read the hijacker guide....

David_Singleton · 2006-12-16

Miklos Hollender wrote:

Ontopic then: have anybody heard of any planned improvements on how commits/rollbacks are handled? Moving it towards a more structured exception handling-related direction?

The prob is, often you have to do things like f.e. during posting a shipment, go to the order, open it, change the qty, relese it again (this is to allow overdeliveries). Or during the posting of an invoice, create and post a bunch of extra journal lines. Something sort of that. Such changes tend to lead to commit/rollback problems. In the first example, you have to commit after reopening the order, otherwise you'll get a runmodal error sometimes, due to the credit limit warning or something like that. But if you then receive an error for any reason, the orders stay open. So what would be needed is a structured exception handling, something along the lines of open the orders - try { whatever } - catch {whatever} - finally {rerelease them} . Or in the second case, if there is an error in posting your journals stay inserted, because there are commits in the posting process. So what would be needed is, like, create the journal - try {post the invoice} - catch {whatever, and delete the leftover journals}

Any plans about it? Or they just expect us to wrap all such stuff in codeunits?

OK, for those that did not understand my original reply ](*,)

This is not a question, it is simply a number of wishes and requests. If you want Navision (Microsoft Dynamics term) to give you and answer, you need to sit down, think rationally, and define a clear question.

PS first time I ever mentioned 42 in a geek type environment, or on any forum for that mater where people did not understand. :roll:

Howdy, Stranger!

Quick Links

Categories

Dynamics-NAV 5.0 vs. 5.1

Comments