We (end users) are experiencing a speed problem with Navision Financials (US 2.00) when calling a third-party created OCX. (I posted a message with more detail in the Integration forum.) Can anyone point me to a description of the process that Navision Financials uses when calling an OCX? The slow-down is so dramatic that I’ve even thought that maybe Navision shoves some of its code or data down the wire to the server before passing control to the OCX! . . . or maybe swaps it out to a file on the client’s disk? If so, can this behavior be tuned with set-up parameters? Any ideas? (or even wild guesses?!) Can anyone share their NF<->OCX experiences? Russ Bellew Radiodetection Corp Mahwah, New Jersey USA russ@rdcorp.com
We use OCX with Navision all the time and do not experience speed issues… Navision does not do stupid stuff like swap to the server… Are you sure your OCX works fast with other calling applications like Visual Basic? Jim Hollcraft aka Skater drilldot.com Unauthorized Navision News
Thanks, Jim, for your reply. “Are you sure your OCX works fast with other calling applications like Visual Basic?” Yes, it does work fast when called from Visual BASIC. Only when called from within Navision does it run slowly. Is there a setup parameter within Navision that could affect what Navision does when it calls an OCX? Also (I am a complete Novice regarding Navision . . .), is it possible to trace Navision’s program execution just before and just after it calls the OCX? Thanks again for your ideas, Russ
Navision has a debug mode that does allowed program execution to be traced but may require Navision granules that you don’t have. I’m not aware of speed problems with OCXs (and I checked the Navision-US dealer level bug database and didn’t find anything there either) so, pardon if I ask stupid questions but … have you commented out the OCX call in the Navision code (say substituting it with Navision code that just returns dummy values without making the actual call to the OCX) and is the speed really fast in this case? That would then help confirm that the problem is coming from the OCX call. One worry I’d have is if the OCX call is happening in the middle of a Navision Transaction… this is probably not your problem today… you wouldn’t get trouble with this until you tried to have multiple concurrent users. So I’d focus on the case of getting a single user at a time fast first… (I’m assuming that is the problem you are trying to solve now.) Jim Hollcraft aka Skater drilldot.com Unauthorized Navision News
Those sound like good troubleshooting ideas, Jim. Later this morning I’ll be meeting with both the OCX programmer and the Navision programmer who’s been provided by our Navision Solution Center. (I must admit that I gag as I type that phrase. What was wrong with “dealer”, “VAR” or “reseller”? But I digress . . .) Thanks very much for searching the dealer-level bug database. You’ve posed a couple of intriguing questions, which I’ll attempt to answer: This is a production system, with multiple users banging on the database. How would OCX calls be affected by the number of concurrent users on the Navision database? Do you recommend that we try testing this while only one user is logged on to the Navision database? I’m not familiar enough with Navision to know precisely how it defines a Navision Transaction; the OCX is called while calculating billing of each order line item. Our NSC is asking us to build a simple Win98 client with only the minimum components required to run Navision, and see how we get along with that. I’ll do this this morning. (I hope that I can partition a disk to allow multiple Win98 systems.) My personal feeling (not shared by the NSC) is that we need to bring in someone who’s been into Navision for at least a few years up to his elbows and has gotten his/her hands dirty with calling external procedure calls from within Navsision. We’ve played a bit with the usual suspects: notably, McAfee Viruscan (yes, it does slightly slow down the OCX process, but only very slightly – nothing like the tens of seconds we’re seeing); FAXserve client (no effect); IPX protocol (no effect); MS CLient for Netware (no effect); ARCserve client (no effect). Thanks again for your continued interested and ideas! Regards, Russ
My concern with calling the OCX in the middle of a transaction (which starts in Navision at the first WRITE and ends at either a COMMIT or at the end of program) is that you could block the other users. In other words, they have to wait until the OCX finishes and then the transcation is over before they can do anything else. Sometimes, blocking looks like slow performance. Another troubleshooting idea is to install Navision on a computer and use it with a local copy of your database and even with a local copy of SQL (ie no network.) This might require a rather difficult computer to configure, but at least you can then start to isolate the problems. As a favor to all of us on the forum, please post your final resolution to this problem. At last I’m very curious to know the cause of your troubles. Jim Hollcraft aka Skater drilldot.com Unauthorized Navision News
Thanks again, Jim (and Craig and Andreas) for your ideas. Today we used a stopwatch to time a number of operations by a user. We tried two Win98 (PII-350) stations: one which has been in service for a year and had a number of applications installed and uninstalled; the other a fresh Win98 install. Both have similar components installed: IE4, IP, IPX, MS Clients for both NetWare and Windows, ARCserve client, FAXserve client, et al. We timed: 1 line calculation, 1 line posting; 4 line calculation, 4 line posting. We timed both stations first with McAfee ViruScan 4.x system scan enabled, then with it disabled. In every case the freshly installed Win98 station was substantially faster than the old Win98 station. Also in every case VirusScan system scan did slow down the operation, on both stations. I’ll try to create a table below (hope that this text editor keeps it intact): Time to complete operation, in seconds: o With ViruScan system scan enabled: Old Station New Station 1 line calc: 7 1 1 line post: 12 5 4 line calc: 23 2 4 line post: 30 7 o With ViruScan system scan DISabled: Old Station New Station 1 line calc: 1 <1 1 line post: 6 3 4 line calc: 7 <1 4 line post: 18 5 Our proposed action is that I will clone (Drive Image and Partition Magic to the rescue!) the partition from the “New” Win98 station to two of the older Win98 stations and test them. We presume that they will perform as quickly as the “New” Win98 station. The unanswered question remains “What caused such a slowdown on the older Win98 stations?”. The “New” Win98 station lacks only a few components taht are on the “Old” WIn98 stations: notably, QuickTime for Windows. However, the “Old” Win98 stations had been subjected to a number of attempts by a previous third party OCX programmer who insisted upon installing a full copy of MS Visual C++(!) on them, since his OCX needed some (unknown) DLL that’s part of Visual C++. The whole transaction smelled fishy, but we let him continue until finally it was clear that he was making no progress. Maybe some DLL that was left behind is causing the slowdown??? I’ll post results again once we’ve copied the fresh Win98 install partition to two of the production clients and test them. Any other ideas about what could be slowing up the older stations? Thanks again for all the thoughtful and prompt ideas from everyone, Russ
I know that it seems odd for mr to reply to myself, but maybe the “.” characters will help preserve the table formatting: Time to complete operation, in seconds: o With ViruScan system scan enabled: …Old Station…New Station 1 line calc: 7…1 1 line post: 12…5 4 line calc: 23…2 4 line post: 30…7 o With ViruScan system scan DISabled: …Old Station…New Station 1 line calc: 1…<1 1 line post: 6…3 4 line calc: 7…<1 4 line post: 18…5
Speaking of smelling fishy… Russ, I have to say that the entire approach to solving a sales tax problem with an OCX accessing a SQL database sounds rather strange. If I were to guess on the optimal architecture (without knowing all your particulars), it would be an import of tax rates into Navision whenever an update was available and all calculations done inside Navision. Navision is an awesome/fast/easy development environment that already handles most US tax situations well. Updating the rates with an external service would really make the whole thing easy. Jim Hollcraft aka Skater drilldot.com Unauthorized Navision News
Interesting, Jim: both you and Craig think that importing the SQL data into a Navision table(s) and doing the calculations within C/AL is a better approach than calling an OCX. Maybe we’ll be forced to try this . . . So far, cloning the partition from our test station to two production stations is discouraging – they (I think) are as slow as before(!). Agggggghh. Will report more later. Thanks again for your insight, Russ