Dynamics and SQL Reporting Services

Hi all, will the SQL Reporting Services be the next Report Designer for Navision (and the other Dynamics Products)[?] I guess we will find out sooner or later. But it allready seems to be an alternative. Here you can download sample reports: http://www.microsoft.com/downloads/details.aspx?familyid=d81722ce-408c-4fb6-a429-2a7ecd62f674&displaylang=en

Oddly Navision UK announced something about this back in 1998 when SQL was getting ready to hit the streets, then a year later denied it. [:D] I think that having one set of SQL reports in standard format that can work accross all platforms is a great step forward, and definitely somethign that we are all expecting. I think that since we still don’t have flow fields in SQL, that they are not going to happen, and the old “create lots of buckets” type technology as in SAP and Oracle is the way we are heading. Itnot great for perfromance, but it makes report writing easy. Just take a look at how share point works, and I think we can see the direction.


I think that since we still don’t have flow fields in SQL, that they are not going to happen

And that’s for a reason. My experience is, that in 90% of the cases SQL Server does a better job calculating sums on it’s own rather than using the awkward Navision flow fields tables. So why complicate and slow down matters? Regards, Thomas

[?] [?] [?] Thomas, I don’t understand your comments, I have been working with FowFields for 15 years, and find them to be one of the greatest features of Navision, why would you say otherwise?

Do not forget that there will be Webservices which can be used to feed the Reporting services in MS SQL… it means, you can still use FlowFields… :slight_smile:

@David I agree that in Navision the flowfields are indeed very powerful and useful. However, the way they have been implemented in SQL causes a lot of extra overhead when you are writing to the database. Each key which uses SIFT creates another table in SQL which needs to get updated via a trigger when records are changed. Also in tables where the records aren’t static (eg sales lines, journals etc) SIFT records don’t get deleted which can waste server space (unless optimize tables is run frequently) Also SQL inherently has the ability to SUM fields in a table without having to make use of SIFT. Obviously SIFT comes in useful where the result set is very large and saves SQL having to read a lot of records. This is the reason for MaintainSIFTIndex in version 4 (SP1??) we can now choose whether or not SQL will use SIFT tables or its SUM command.

I think we are all getting crossed lines here [;)] the biggest issue that I see is that SQL does not support flow fields. So they are instead generated on the fly with scripts, that aintaint ht eSIFT fields in seperate tables, and that does cause performance issues. It would be great if SQL incorporated SIFT technology native. So I think then that we can all agre that the concept of Flow Fields and SIFT technology is great, but trying to implement Flowfields without Native SIFT is nto an ideal solution.