SamCG has asked for the wisdom of the Perl Monks concerning the following question:

Has anyone worked with Navision, either using an ODBC connection or with their .zup files? Searches on the internet have been remarkably fruitless.

The accounting department has recently asked the IT dept to support Navision, and one irritating factor is the .zup files, which need to be deleted and re-created on each machine when changing databases or servers. An edit program, particularly one that could automatically change certain values, would be useful. Has anyone looked at zup files and have an idea of how to approach them, either editing, reading, or creating according to Navision's requirements?

The other issue we're having is with Navision's ODBC module, which one of our consultants is trying to work use to run queries (actually accessing it through Excel and MSQuery!). His problem is that the queries are taking a very long time. He thinks the ODBC module is downloading the entire database; I suspect the technique might be flawed. Has anyone connected to Navision's database (note: it's not Sql Server) through perl?

Any help/pointers appreciated. . .sorry about the lack of specificity, but I don't really have any code yet.

2004-12-11 Edited by Arunbear: Changed title from 'Navision questions', as per Monastery guidelines

Replies are listed 'Best First'.
Re: (OT) Navision questions
by gellyfish (Monsignor) on Dec 02, 2004 at 18:05 UTC

    The only time I have ever worked with Navision it had an SQL Server database so I can't help you with the former point. I would recommend that you (or someone in a position of some weight) recommend that you migrate to SQL Server - this will save a lot of pain and anguish in the long term.

    As to the second point, what I would suggest is that you use the ODBC connection to copy the data into a second database from which you can run the reports, thus only taking the hit once.

    Quite what this has to do with Perl I'm not sure.

    /J\

      Thanks gelly,

      Technically not really much to do with perl, except it would give me an excuse to evangelize and perl hackers tend to be wide-ranging in their exposure to various technologies (and general information on these topics is rather scarce).

      I'll try recommending SQL Server, though they stopped listening to me a while ago and most of those with any weight have an inverse proportion of technical sense.