Vote for a better Development Environment

Johannes_Nielsen · 2014-06-13

Hi all

Just wanted to share this suggestion.
It's not mine, but I feel every C/AL developer should give it a vote, to show MS that the Dev. Env. really does require a major update.

https://connect.microsoft.com/dynamicssuggestions/feedback/details/882349/development-client-in-visual-studio-and-integrtion-for-team-foundation-server

If you're not aware, MS Connect is a place to suggest improvements and features for MS products, including Dynamics.
Take a look and vote for the entries you agree to or comment on them.

Alex_Chow · 2014-06-13

No.

C/SIDE is not a development tool. It's a tool to customize NAV product. I feel like the more things that MS tries to "enhance" it, the worst off we're all going to be.

Johannes_Nielsen · 2014-06-14

Alex Chow wrote:

No.

C/SIDE is not a development tool. It's a tool to customize NAV product. I feel like the more things that MS tries to "enhance" it, the worst off we're all going to be.

Not true, C/SIDE is an IDE - and it should start behaving like a contemporary one.

They tend to screw thing up, I'll give you that, but the Dev. Env is very old and other IDE's have moved on. You don't have to spend many minutes in Visual Studio to see stuff that makes you turn green of envy.

Wouldn't features like "Where used", Intellisense and Object Versioning, Code versioning make your life easier?

I have separate tools for Code commenting, Object Versioning, FOB viewer, Where used, Mergetool. And no, they are not "Add-ins" - because that is not possible with C/SIDE

Miklos_Hollender · 2014-06-16

I disagree. This would be useful mostly to those who make major add-ons. As major add-on making is how Navision programming is similar to "general" programming, and thus a Navision IDE similar to a general IDE would be useful.

I think major add-on builders are a special minority. I did it once, and it was en entirely a different experience - much closer to "normal" programming than the usual projects, and yes I wished for a modern IDE. But for most of us it is more like supporting and customizing the standard NAV. For that different tools are more useful.

Most of us needs speed and flexibility for small tasks, we don't often have large ones. E.g. add a Document Outline to SQL Report Builder so that we don't have to install a huge clunky Visual Studio to production servers in order to be able to do minor report corrections - without a Document Outline it is almost impossible to find important stuff in that huge mess that is standard reports.

I think what we would need above all is more stability to not have to deal with "platform error messages" that scare the living daylights out of our users.

Or for example in core functionality NAV still does not support the EU economy as such properly. Once you have departments in multiple EU countries making VAT and Intrastat match is a hell.

So there is a lot of things they could focus on that IMHO would help more people.

Johannes_Nielsen · 2014-06-16

Miklos Hollender wrote:

I disagree.quote]

Well, I can compare it to driving a French car from the 80's og 90's where the pedals aren't aligned with the seat and the horn is placed on the wiper stalk.

If you have a good driving position a rally driver can really go fast in your car.
It works with the daily driver aswell who goes slowly.

Ruin the driving position, the professional cannot do his job.
But the daily driver can still go slow.

As you said - the IDE is'nt good at anything but limited customizations.
We cannot all go slow - code is code, and the tools are well known - lets have them

Miklos_Hollender · 2014-06-16

The problem with your example is that Microsoft is having limited capacities and it would take away capacity from more serious issues. Slow development is only a problem if you develop something big - although in my experience big add-on development is 90% thinking and 10% typing. However the much more crucial issues happen on the basic level of the application not being properly usable and being perceived as annoying by users, and the crucially important lightning-fast fixes ("add that to this delivery note the truck is waiting and I only noticed now it is missing!") being hindered.

Sure, if it would not use capacities I would support this because why not, but I would not support it if it takes capacities away from other things, or even if it makes Microsoft thinks this is is what the user- and partnerbase needs as a first priority - in reality what we need as a first priority is a modern NAV5.0 so to speak: stable base application and easy and fast small changed because without it is simply not seen as business-ready by many.

Priorities should be held in proper order in order not to make the less important things overshadow the most important ones. For example just yesterday I saw some user being super upset that the Excel export did not work probably because there was a funny character somewhere in the table and he told me that he cannot have tools that may work or may not: he must rely on them 100% because he is working 10 hours a day and every small bug is adding hours to it. I saw his point quickly. And it was in the stable and mature Classic environment. In 2013 he would have more similar problems, at least my tests so far suggest that. This is why I would say that Microsoft must now focus on base application stability and not take any capacities away from it and put them on the IDE - even our good old Classic was not stable enough to really be able to guarantee people that their tools work 100% reliable.

Johannes_Nielsen · 2014-06-16

Well sure, modernizing the IDE will take up some resources, however, it's due for a makeover

But I don't think the good people working on the NAV base application would be doing it anyways.

Actually, please outsource the job.
After all, MS is a world class leader in IDE's with Visual Studio...

jglathe · 2014-06-16

Miklos Hollender wrote:

Priorities should be held in proper order in order not to make the less important things overshadow the most important ones.

From my point of view that is turned upside down at Micrsoft since at least 2008.

And guess what? They are still rambling about "user experience"... I have the urge to throw up every time I hear this. The UI is totally fucked up, reports are dead in the water. The business logic is filling up with (incomplete) hotfixes faster than you can say "Cumulative Update". The so-called "user stories" are getting even shallower with every release. And even these DON'T WORK, ffs. Or only in the sales demo without the tarbrush of reality.
Back to the topic: I would find it a good step into the right direction when we could get either a properly-featured standalone IDE (even removing the nastier quirks of the last 10 years would be a plus) including reports or a complete integration into VS. But realistically we're talking about a horse that's... well... smelling funny. So, in the end it doesn't matter what the dev environment is, when nobody is selling the new version.

Miklos_Hollender · 2014-06-17

@jglathe the only thing I disagree with is that nobody is selling the new version. People do, because the cancellation of support for the old ones is a serious threat.

Here is a hypothetical scenario. Tomorrow Microsoft realizes that Navision is not actually compliant with EU regulation. E.g. if you have a company in Germany and have a separate VAT UID and business department in Austria but not an actual subsidiary, and you move goods from one to another with a Transfer Order, you need to report an intra-community VAT (IG Verbringung). And yes, it should match with the Intrastat in value. And it is not just making a few VAT Entries as as you probably know the tax office in Germany is very keen on having everything VAT related also booked in the G/L, this why stuff like Report 11009 were made. So it is a major thing. Suppose Microsoft gets wise and does it in Crete. What are we going to do, downgrade it? Sooner or later such downgrades just add up. And maybe two years later you realize you cannot install Classic on a Windows 9 for example. OK you work it around using and old server and RDP... or whatever. But sooner or later it really adds up so the wise thing is to choose the most flexible and tolerant subsidiaries or customers and start upgrading them now...

jglathe · 2014-06-17

Hi Miklos,

I understand your POV, but I tend to disagree. The threat of nonconformity or missing support is almost the same as now, iow nonexistent. When you need a working solution, you *may* be able to use what Microsoft delivers as a regulatory upgrade. As as base for your own implementation. Or (like is the case with the XBRL nightmare in germany) you "roll your own", or buy a proven third-party package with a NAV interface. We have solved this with a custom-built DATEV interface, as an example. It wasn't the obvious choice, but apparently one of the better ones for our use case.
The real threat that I see that the company ends up with an ERP system that it is struggling to use, but doesn't live up to previous productivity levels. It is less actually usable functionality for the same (or higher) price, and it kills old working features. Bad idea, this. So, if you're looking from the business continuity POV, you would avoid the upgrading threadmill and keep it working as long as economically feasible, while looking for a replacement product in the mid-term (however, NOT Microsoft). Real-world EOL will be around 2020, IMO. So, by 2017/18 you should have a replacement product for a pilot migration.

with best regards

Jens

geordie · 2014-06-23

I'd rather vote at least for a fully "Undo" functionality, it's quite uncomfortable being able to reverse changes only if not moved on another code line.

Johannes_Nielsen · 2014-06-23

geordie wrote:

I'd rather vote at least for a fully "Undo" functionality, it's quite uncomfortable being able to reverse changes only if not moved on another code line.

That is exactly what "Team Foundation Server" (TFS) or another code repository can do, amongst many other things like automatic/assisted merge.

Your vote should be positive :thumbsup:

defiant701 · 2014-06-23

Again nice discussion about old and new NAV world. There is still the majority of partners (mostly in Germany) that belong to the old world damned in their project methodology from the 80s/90s. Would be interesting to see what remains in the end. My bet is the new world (THX to 3tier, RTC, AZURE, WCF, .net .....or let's say I like it :thumbsup: ).

Miklos_Hollender · 2014-06-24

@defiant701

What is the old/new world, what do you mean by 80's / 90's and today?

My story and viewpoint: I worked first in Hungary, where add-ons were almost unknown and we sold standard+customizations. I did the same in the UK, then I realized at moving to Austria that in AT, DE, DK, NL there is a strong focus on add-ons and much customizations are kind of frowned upon, because there is a certain business culture of standardization valued and "everybody cooking their own soup" kind of disliked. or something like that. (Except in cases where a dev licence is bought by a larger end-user and they basically make something like an add-on for themselves. A certain large sports clothes maker company comes to mind. I too work in a similar situation although in an entirely different industry.)

At any rate, those who focus on add-ons are more able to adopt modern technologies like automated testing or code repositories, like modern IDE's, often have a lot of knowledge in "traditional" non-C/AL style programming like C# and so on, have "real" programmers, and in this sense are "more modern". However they are typically more of a standard software development company, not project focused but product focused, can't really said to have a project metholodology beyond "install, set up and train the add-on", and this is not exactly new. One could even argue that the golden age of add-ons was more in the 90's, with Navision Financials because that was such a limited product that it was not very useful without add-ons. So, add-on makers are often more modern, but this is not really a new thing and not really a project methodology. This is more common in business cultures that value standardization, like DACH, NL, DK and interesitngly, I think, the USA.

Those who focus on implementing the standard with customizations are different, they often make many smaller developments not a few big ones, often have consultants with a business or system analyst background who retrained themselves into C/AL programming who are not like "real" programmers and don't like C# or Visual Studio much, they see less need for modern tools. However their methodology is really a project methodology, project not product focused, and actually this approach became _more_ viable since the 90's as the standard product became better. This is more often the case in cultures that value individualism and "have it your own way" over standardization like the UK, HU or I suspect much of Eastern Europe actually.

So from this angle it is not quite clear which one is more modern.

Another thing is that you mentioned Azure, WCF, my general hunch is that in a traditional ERP setup with sales assistants or financial assistants sitting in an office doing data entry all day, they are not tha useful actually. A traditional ERP setup actually even worked better before GUI's, like SAP R/2 with terminal emulation, they were faster for data entry and sometimes we got to automatize it without changing the application itself - just making terminal emulator scripts. At any rate Azure, WCF are probably not too useful for the standard + customization type business unless Microsoft themselves integrates it in an easily customizable way... I think they rather open horizons for add-on makers. My hunch is that we are going to see add-ons that integrate ERP with other devices and applications that are traditionally not integrated.

Then we have all this multi-tenant thing especially meant for hosted solutions, often renting software as opposed to buying it. One thing is clear, namely that it is not meant to be really customized a lot. So either add-ons or trying to get away with a standard not much modified. Small-business focus. "Repeatable business".

If Mark Brummel is right, and Microsoft is focusing now on "repeatable business", it means that they don't see the sell the standard + 100 days to customize it projects sustainable in the longer run.

Anyway, so the point is that there are at least 3-4 different angles from which this modern vs. 90's thing can be analysed...

defiant701 · 2014-06-24

Miklos Hollender wrote:

@defiant701

What is the old/new world, what do you mean by 80's / 90's and today?

Hi Miklos,

I focus on the partner network that I've been working for a long time in many counties. It was always the same "come for the project" & "go for the project". Each new customer got it's gap/fit workshop and a list of desired features. Often with completely ignoring the standard. Of course every time individually (especially in D/A/CH region).

Miklos Hollender wrote:

If Mark Brummel is right, and Microsoft is focusing now on "repeatable business", it means that they don't see the sell the standard + 100 days to customize it projects sustainable in the longer run.

Mark is absolutely right that MS focuses on repeatable business solutions and from my perspective they are right. Today my business has changed massively. We do not have on premise installations anymore only on AZURE, we provide open service interfaces related to processes, half of our team are .net coders for integrating the world with NAV business logic, we provide multi-tenant installations without individual coding and we can provide world wide installations via powershell scripts together with 3 party solutions on the same level. And that's highly repeatable and sustainable. Most of my former comrade-in-arms work for partners who have all problems to keep their customers up to date.

For me the new approaches have much more opportunities than the old ones.

Miklos_Hollender · 2014-06-25

@defiant701 quite interesting. Looks like you have clients who are keenly interested in the latest technologies - perhaps they themselves are a form of a tech company. Frankly I personally don't see a lot of demand for the new technologies in the fields I am most familiar with (distribution, wholesale, retail, manufacturing, construction), I always get the impression that if plain simply the whole Classic stuff would be supported for another 10 years everybody would be OK with it. Few people I know seem to care - or even know - about stuff like web services. Apparently the kind of integration where you just read the SQL tables of other apps through ADO is good enough. Well, ERP always used to be a slowly moving industry - we adopted XMLPorts in like 2004, when non-ERP web apps already knew and used XML around 1998...

rdebath · 2014-06-25

Nav is supposed to be a 'Rapid development environment'; When I'm using V5 it still is; the menusuites have no flexibility but otherwise it's fine.

I do have object versioning/recording/differencing, I do have "Where used"; I don't have "intellisense" -- I really, really do NOT want it. The editor is clean and keeps up without any problem. The "F5" function is a bit limited, but really it does the job. The one thing I do miss from V6+ is the "goto definition".

With the RTC involved things start stuttering; saving an object just hangs for (what seems like) ages; especially if it's a report and editing reports starts visual studio ...

Visual Studio is VERY slow, it doesn't really keep up with my typing and (if I ever have it turned on) intellisense usually just gets in the way. The RDLC reports for RTC are just a disaster (and medium sized reports keep running out of memory and large reports almost impossible) with almost no way to predict how anything but the most basic layout will react.

The difference between development speed on classic reports and RTC reports is about three to one; THIS IS FOR PEOPLE WHO ARE COMPETENT WITH THE TOOLS. A big part of that is the slowness of the tools and the unpredictability of the RDLC. I really don't want to be forced to use these same tools for C/AL development.

** (where used and versions are not Microsoft supplied though)

Johannes_Nielsen · 2014-06-25

Wow, the NAV RDLC adventure is really backfiring it seems.

RDLC tasks are not my favorites - actually, I'd rather use anything on this earth than RDLC. Classic reports were limited and had their own quirks, but they could be very powerful. RDLC is alot of confusing fiddeling.

But please - do not confuse a modern IDE (like VS) with the RDLC layouter(which uses VS , but has no relation to the code editor).

This topic is about the IDE and writing code more efficiently by introducing basic tools, available to most programmers in 2014.

RDLC was different (new) technology, badly shoehorned in NAV, bringing a lot of grief to anybody who touches it.

Modernizing the IDE shouldn't repeat the same mistakes. And I have to be confident MS won't. Because I cannot accept the alternative, which is the IDE never improving, when there clearly is room for improvement.
Just don't mock it up! :roll: Here's the spirit I'm looking for https://www.youtube.com/watch?v=_gQ84-vWNGU

Miklos_Hollender · 2014-06-26

I am not sure what is the correct term, perhaps the "rapid development" @rdebath is using or something else, but it seems there are two very different "traditions" of development environment. The "tradition" C/SIDE belongs to is roughly similar to Visual FoxPro, MS Access, back in ancient times the CA-Clipper and for more modern open source alternartives check out http://www.wakanda.org/ and http://dabodev.com . This approach, sometimes called "rapid application development" but I would prefer to call it more like "data centric" or even "inversion of control" enables you to do develop bare-bones database applications even without writing a line of code, roughly the same way you would do it in NAV - make a table, make a list and card form that has create/update/delete functionality built-in to the framework, same way for basic reports, and generally speaking programming is only used to give it extra "intelligence". This is also sometimes called "inversion of control" because instead of your main program calling functions from the framework, it is the framework that reacts to the user action e.g. inserting a new record, and calls your code for validation etc.

The other approach, the other "tradition", of which Visual Studio is a heir of, is not data-centric but more like computation oriented, focuses on algorythms. This goes all the way back to Java, C, Delphi etc.

Whiling combining the two is certainly possible, they are fairly different philosophies.

Miklos_Hollender · 2014-06-26

As for the RDLC adventure... when I started working with Navision around 12 years ago I was really, really surprised that documents were handled as just reports running on posted header/line tables. I was used to entirely different document creation methods in other (local) accounting software, where nobody thought documents are just a kind of report.

In those software reports were basically tabular queries on the screen (like something like an Item Analysis View) that you could export to Excel, view, or in rare cases print. Documents were entirely different in those other software. Basically... imagine as if the Print Preview of an invoice would be editable like a Word document, so in a really document like document format. And that would be unposted invoice window in your screen. Yo would be free to add texts, remove whitespace etc. while of course the fields like unit price would be less flexible as they have accounting consequences. And you could print it and send to your customer and only post it when they have accepted it.

So back then I was really bummed by the Navision logic that your invoice is merely a printout of the posted transaction and you cannot even edit it after you (posted and) printed it. But despite this really weird idea that documents like invoices are treated as reports instead of more like editable letters or fillable forms, we could massage Classic into usable documents 95% of the time - although in some cases we had to accept lots of unused free space when we had many conditional footers for example. We made tools that we designed the printed invoice report to look good and then we would export it in text and use the tool to turn it into an unposted invoice report, so that they can print and see how it looks like before posting. We have made a tool that if you _still_ managed to screw up say the customer name, a button push would copy a credit note, post it, then copy it an unposted invoice and pop it up so you could easily correct it and post it again. So it was hard, but we could cope with these additional developments.

Yet it was weird that Navision treats documents as reports.

Apparently, Microsoft did not realize that, as the Classic reporting paradigm, while weird, was sort of usable for documents. So when they wanted to make a new one, they took a good reporting solution, RDLC, which is excellent for SQL based reporting, and did not even consider that something that good for reporting might be problematic for documents.

I am not really sure what is going to happen in the longer run. I think sooner or later a partner will make an add-on that will leave the whole RDLC out of the documents.

Johannes_Nielsen · 2014-06-26

Miklos, you should start a blog, I enjoy reading about your views on NAV

You're right that Classic reports are well suited for documents, god knows RDLC isn't.
The ability to edit the invoice document, NOT lines ect., but free text etc. using WYSIWYG sounds cool..

On the plus side:
In my world BI and Reporting needs should move to Excel and PowerPivot using Queries. If you can afford NAV, you're using Excel already.
Documents still have a place, but I wonder if some workflows could be redesigned, since they originate from a time where documents existed physically...

Alex_Chow · 2014-06-26

Here's a compromise. Keep the existing IDE. If you want to use VS to modify NAV, export the object into .txt. file and open it with Visual Studio. Modify the code then import it back into NAV as text and compile it.

Johannes_Nielsen · 2014-06-26

Alex Chow wrote:

Here's a compromise. Keep the existing IDE. If you want to use VS to modify NAV, export the object into .txt. file and open it with Visual Studio. Modify the code then import it back into NAV as text and compile it.

Be serious

davmac1 · 2014-06-27

I think the problem is trying to design the new reports like the old reports.
Trying to emulate Classic can make life difficult.

The newer versions of Visual Studio make group headers and footers the preferable way to handle document reports instead of page headers and page footers.
We also have drill down capability to other reports and pages which can make the new reports highly interactive and maybe cut down on paper.

Summary reports should be summarized in NAV code not Visual Studio. (Microsoft standard not followed by Microsoft unfortunately.)

We also get some new report types - like matrix reports.

tinoruijs · 2014-06-27

davmac1 wrote:

Summary reports should be summarized in NAV code not Visual Studio. (Microsoft standard not followed by Microsoft unfortunately.)

This is the problem. Microsoft employees seem to have the same problem as we do and that is lack of experience with the new tools.
I think this will never change and is inherent to the business we're in. It's the downside of progress.

Miklos_Hollender · 2014-06-27

@Johannes Nielsen when RDLC was first introduced I began moving more my reports that are actual reports away from the printable paradigm and towards the Excel Buffer. Later on I realized this is an actually superior way of doing it, because with minimal customizations they can be scheduled and e-mailed automatically daily, weekly, or monthly, so the first time in history non-technical managers who don't even have a NAV username can have a daily and weekly overview of what happening on the business, even on a smartphone if that can read Excel, it opened up enormous potential for the top management to spot problems and act on the early.

However documents are a bit of a different story. For example the world on one hand is moving towards electronic documents, you guys have this OIOXML invoices in Denmark, there is EDIFACT in a lot of other countries, all sorts of XML interfaces and so on. This obviously looks very good (except that EDIFACT is horribly, horribly, horribly un-Microsofty, stone-age old, and downright WEIRD if you are used to typical Windows solutions. You cannot even send them per E-mail or (S)FTP for goodness's sake, like you ever sane Windows solution would, you have to use some weird communication technology called X.400 Telebox or AS/2 so even our IT guys scratched their heads and asked what the sweet heck on Earth is even that? When we had to implement it.) But yeah except for the fact that some helpful comet should really make the EDIFACT dinosaurs extinct and replace them with with honest-to-Windows 21st century technologies, this is a very promising future.

However! The trouble is that a document is 1) a letter to a client that creates an impression of your company (especially quotes) 2) it is a legal document between vendor and customer (especially invoices) that is the basis of collection of payments, business can be sued when they don't pay an invoice 3) it is legal document for the government to collect taxes (VAT) - and people don't like much to pay taxes, they try finding backdoor and governments try closing them down.

These two obviously contradict and generally it looks like this. You have a large, organized, automated company making or importing juicers. You have some large, organized, automated customers like Aurora, Euronics or Media Markt and you ship them every week, years and years and years on. In this case you almost certainly implement some kind of an electronic document interchange, send XML or EDIFACT orders and invoices and with that it is solved. However. You have a smaller company who lives off random deals whenever they can find them, a company that is not so automated and industrial and everything being process based, not, but more like a random flexible, clever company hunting for deals whenever they can find them. One-off customers, usually small, different deals. In this case all three of the above matters. You want to send out beautiful and perfect looking quotes and order confirmations to create a good impression. You want to be able to put every possible legal text on your documents to make sure you can collect money. And the customer will often have "creative" ideas to deal with taxes, they may want to have special requirements of what they want to see on an invoice. And of course governments don't like that you there will be all kinds of special rules, for example if your customer is in Italy (and you made a subsidiary there or at least a department with their own VAT Reg. No.) you must deduct the payment discount from the invoice total and make sure you have no gaps on invoice numbers. If they are in Hungary you cannot always credit wrong invoices, sometimes you must make a "correctional invoice". If they are in Germany they really expect the Intra-Community VAT reports to match with the Intrastat. And so on. All this points towards the need for really, really, really flexible paper based documents.

Miklos_Hollender · 2014-06-27

@tinoruijs

>I think this will never change and is inherent to the business we're in. It's the downside of progress.

Actually the typical characteristic of the ERP industry is that it moves slower than other kinds of software because of the need for stability, reliability, and because of sometimes decades long investments into business logic. Go to a bank or insurance firm and you will find folks still writing code in COBOL because they are just not going to throw something out they were building since 1978. Distribution, manufacturing etc. so our usual victims

are of course less crazy in that respect, still it is slower moving, because it values stability more.

There are about 4x more NAV than AX installations. And the reason is not that AX is lacking in features or programmability, to the contrary, it is actually better in both. The real reason is that about 10 years ago or so when I tried working with it (Axapta 3.0) it was so ridiculously unstable and unreliable that it was often seen as not a "serious" offer. They were simply different philosophies - the Navision team valued stability and only adopted new technologies only when they were fairly sure it will work reliably. The Damgaard/Axapta team valued latest technologies, fast progress, and adopted the latest bleeding edge technology even when it was not really matured. It was basically two different business cultures and the Navision approach proved to be more succesful than the Damgaard/Axapta approach.

This was changed since the RTC, now it is more like fast progress at the price of lower reliability and maturity. I wonder what will happen in the longer run though. What I see is that as larger Microsoft technologies, like SQL Server and Visual Studio seem to have changed for 2 year release cycles it seems the general culture of Microsoft is moving towards faster change.

Similarly the resistance against this fast change is not just a Navision thing. Everybody in our office or really everybody I know is still using Windows 7, there is just no interest in 8/8.1, as it is just working well enough the way it is. It is not active resistance, just disinterest. And even the reason why we use Windows 7 is that Vista was kind of bad, maybe if Vista is a "better XP" we would still be using that. I see similarly little interest in Office beyond 2010.

ppavuk · 2014-06-27

rdebath wrote:

The RDLC reports for RTC are just a disaster (and medium sized reports keep running out of memory and large reports almost impossible) with almost no way to predict how anything but the most basic layout will react.

The difference between development speed on classic reports and RTC reports is about three to one; THIS IS FOR PEOPLE WHO ARE COMPETENT WITH THE TOOLS.

Honestly, 3 month before i would agree with you, but now, after making a dozens of RDLC reports - i'd better say that new report designer is far better that old one.

rdebath · 2014-06-30

Sorry for the lack of replies; been fixing NAV2013.

I have been using visual studio for a long time, not just the recent RDLC linkage to Nav but all the way back to the V6 days. It has never been a 'good', 'reliable' or 'fast' solution. It's always been in the 'works sort of ok' category. There have been a LOT of external tools consolidated into VS, this is yet another 'sort of works' problem because it always slows VS down so even with really fast hardware VS can't keep up!

Navision's editor OTOH has always been very quick and light, sure it was missing (almost) essential features (like undo!) but what it does have works reliably and quickly.

Just to put both to shame, there are editors out there that can handle 100Mbytes of source in one file easily. Able to load text files of over a gigabyte into memory in 20 seconds and move around, search and edit the file without noticeable pauses. And still do 'Syntax highlighting', 'Where used', 'Goto definition', 'Infinite undo', etc (Though it's probably a good idea to turn off syntax highlighting on a gigabyte file!)

Now what I'd like to be able to do is use my favourite one of those editors (you wouldn't like it; not if you like VS) with 'instant' integration into Nav. And I do mean 'integration' by the dictionary definition where independent tools are integrated together not the VS definition which would more normally be called 'consolidation'. Another tool I would like to integrate with is a good distributed source control system, like Bazaar, Bit Keeper, Git or Mercurial.

The crazy thing is that if Nav could integrate with (say) Git it would make distributing changes to multiple databases painless. So much so that Microsoft's "tenants" solution would be unnecessary.

:sigh:

rdebath · 2014-06-30

I definitely agree with the comments re stability of Navision vs. Axapta. Axapta looked nice, and had the nice ability to embed other tools (eg MSIE windows) but the few crashes we had with Navision could be traced and avoided very easily. Axapta, not so much. Nav 2013, Well ... Deleting tables that contain user data! :shock: :-x

Re: Miklos: Documents vs Reports. Hell yes! The Navision reporting was so 'old school' it should be listed with core memory. It's was practically unchanged since lineprinters. We've used Excel, MS-Word, MSIE and several other programs as print drivers before now. It's a lot of work but can get very good results ... until it crashes. I do keep coming back to the idea that perhaps it would be a good idea to write the report/document in Postscript ... but I really dislike stack based languages. (Not to mention it being very low level)

RDLC isn't that old, but it is weird combination of old lineprinter style 'reserve fixed space for a section' and document style 'fixed position on a page' but mostly without the document style 'measure it so it fits'. You can get stable results from RDLC, but you basically have to ignore half of the 'language' and add several workarounds to reduce the worst of the remaining problems.

Miklos_Hollender · 2014-07-01

@rdebath

Would it be possible to publish a short list of workarounds or at least the major problems? Because I think still not everybody has a lot of experience with it and it is always painfully embarassing when issues with documents pop up in the worst possible minute like the proverbial lorrry waiting for the delivery note, so at the very list it would be helpful to collaborate on a list of "what to test if you don't want to embarrass yourself with the documents at the customer".

Howdy, Stranger!

Quick Links

Categories

Vote for a better Development Environment

Comments