Has anyone ever seen a commercially developed database that works like the Navision database? In other words, is there a product (like Delphi or FoxPro) that has a things like flow fields? I know that there are several, like those mentioned above, that you can do development, forms design, etc, but the flow fields really set the Navi database apart from anything else. I can’t think of anything in the USA like this, but I’m wondering about anything that might be available overseas. Thanks!
To the best of my knowledge, Flowfields are unique to Navision. In addition, I believe the way the native Navision database handles commit/rollback through “versioning” (discarding the updated version rather than actually rolling back a backup copy) is also unique to Navision. Both of these capabilities contribute significantly to Navision’s performance capabilties. At the risk of inviting adverse comment, in my many, many years as a developer, I have not seen a database any more robust and resistent to corruption than Navision’s. Navision’s database is also the easiest database to administer that I have seen. Personally, I think it is a fantastic product. Other people have better IDE’s but not a better database (accepting the limitation that it is not general purpose). Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner
SIFT (Sum Index Flow Technology) is patented by Navision. So you won’t find flow-fields anywhere else, except Navision would have sold that technology. And as far as i know that never happened.
FlowFields and SIFT are two separate things. FlowFields are basically Calculated or Computed fields as provided in other databases. SIFT is a performance feature only; FlowFields can exist without SIFT.
Hi Robert, as we are here in a Navision Forum, i thought we speak of flow fields that also perform like the ones in Navision ;-). And without SIFT the Navision Flow Fields would not. Of course you are right and SIFT is a matter of performance. But as i understand it - that’s what is’s all about. Regards Richard
FlowFields can indeed perform without SIFT. Up until recently, C/SIDE has required that a suitable SIFT key be present when specifying a FlowField that references the SIFT table and key. But this requirement has been removed in Attain. For the SQL version, it has always been the case (since 2.5) that SIFT can be completely disabled even though the FlowField is completely functional, and in selected keys in the Attain base application, SIFT has been disabled in this way. The performance is improved when disabled, since SIFT is not necessary and is an overhead in these situations.
Robert, Please explain how you create a SumindexField then?? The SumIndexField is the basis on which a FlowField is calculated, and since a SumIndexField is always attached to a specific key, I doubt your conclusion is correct. Lars Strøm Valsted Head of Project and Analysis Columbus IT Partner A/S www.columbusitpartner.com
Hi Robert, you wrote: >FlowFields can indeed perform without SIFT. Up until recently, C/SIDE has >required that a suitable SIFT key be present when specifying a FlowField that >references the SIFT table and key. But this requirement has been removed in >Attain. I’m sorry, but that’s definitly not right. If there is no key matching your CalcFormula with the appropriate SumIndexFields, then your FlowField does not work. That’s not a question of speed - it works not at all. The well known message you would receive is: “The Flow Field Value cannot be calculated. You must define and activate…”. No matter which version you use - also Attain 3.01A. Try it. Disable all secondary keys on the “G/L Entry” and then try to run “G/L Account”.
But that is not what was said, There is a proerty on each key called MaintainSIFTIndex, set this to NO and sift indexes are not maintained and flow fields still work.?? Paul Baxter
The property is only valid on SQL - it has no effect on Native database (that means, SIFTs are always maintained on Native database). The help text for the property reads: “This property determines whether SIFT structures should be created (when set to Yes) or dropped (when set to No) in SQL Server to support the corresponding SumIndexFields for the Navision Attain key. SumIndexFields are created in Navision Attain to support, for example, FlowField calculations and other fast summing operations. SQL Server can sum numeric data by scanning the table. If the SIFT structures exist for the SumIndexFields, summing the fields will be faster, especially for large sets of records, but modifications to the table will be slower since the SIFT structures must also be maintained. In situations where SumIndexFields must be created on a key to allow FlowField calculations, but the calculations are performed infrequently or on small sets of data, you can disable this property to prevent slow modifications to the table.” Lars Strøm Valsted Head of Project and Analysis Columbus IT Partner A/S www.columbusitpartner.com
Sorry, I have caused some confusion - my fault! Richard, you are right. The error message is still present in the shipped 3.01A (and B). I should have checked before posting. Let me try to undo the damage 
There has been a lot of investigation recently into the effect of expensive SIFT keys on the SQL solution, and one of the reasons for the large numbers of such keys is the requirement of FlowFields that a SIFT key exists (in both platforms). In many situations SIFT is simply not needed since the filtered set of records is so low. But update performance (and concurrency) can suffer from the presense of SIFT. This requirement was removed during the 3.00 (Solutions) version of the product, but only for internal builds (i.e. it was never released) up until and including 3.10. That means that the FlowField functions without the presense of the SIFT key, for both database platforms. The error message is a safe-guard to prevent FlowFields being created without SIFT to support it, performance-wise. And that is sensible, but leads to many useless SIFT keys that just carry a performance overhead when porting to the SQL platform. C/SIDE is capable of evaluating a FlowField, without the presense of SIFT in the DBM - that is, Navision Server - which was the point I was trying to make. In practice, that is unimportant since the constraint is still active in the product. The new SIFT key property in the upcomming 3.10, “SIFTLevelsToMaintain”, can address some of the update performance issues with SIFT on the SQL platform. I think this has drifted a little off-subject.