Web Services with Microsoft Dynamics NAV 5.0 file size limit

remarkremark Member Posts: 122
Hello,
I am trying to use Web Services with Microsoft Dynamics NAV 5.0, based on this example:
http://blogs.msdn.com/nav/archive/2008/ ... v-5-0.aspx

I can't resolve an issue with reading NAV data of some size, larger than particular value (in fact, relatively not very large at all - 4 MB of final target XML file).
All WCF service limits, which can prevent reading of large packs of data, are set to maximum or very large values. I mean, for example:
       <bindings>
            <basicHttpBinding>
                <binding name="NAVBinding_ICustomer_Service" closeTimeout="01:50:00"
                    openTimeout="01:50:00" receiveTimeout="01:50:00" sendTimeout="01:50:00"
                    allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferSize="2147483647" maxBufferPoolSize="2147483647"
                    maxReceivedMessageSize="2147483647" messageEncoding="Text"
                    textEncoding="utf-8" transferMode="Buffered" useDefaultWebProxy="true">
                    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
                        maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
.................

but, nevertheless, connection still keeps closing without specifying reason for it.
Files of less size are read OK.
It seems, there is something else that causes this problem. ](*,)

Comments

  • ara3nara3n Member Posts: 9,256
    You would have to contact MS to see where they have put a limit.

    I would rather do an exe upgrade for a 5.0 db and use 2009 webservices.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • remarkremark Member Posts: 122
    Thanks, Rashed.

    Yes, it seems that contacting MS is the only way out, and maybe I will try it, though I don't very much believe they will answer something, because it is not an official release of a product or an enhancement to a product - it is an example of a probable implementation in a blog article (though it is NAV Team blog) and the author of the article has disabled the new comments to the post because of release of the NAV 2009 with out-of-the-box support of web services functionality. The funny thing and the problem is that a big part of the world (including Russia) has not yet official release of NAV 2009. And it is also the reason why I can't use thechnical upgrade to NAV 2009 for using its web services features.

    Regards
  • ara3nara3n Member Posts: 9,256
    The other option is to write the message to a file and trigger NAS to pickup the file and process it.

    When are they going to release 2009 in Russia? Is it possible to use the W1 version?
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • remarkremark Member Posts: 122
    Yes, I thought about NAS, but in my case, I think, I will just devide transmission into several parts.

    Nobody says exactly when they are going to release NAV 2009 for Russia, but rumors are - it will take place at the third quater of 2010.
    What about W1, to be honest didn't think about it. I think I will contact MS on this. Do you think it can be possible in legal terms?
  • ara3nara3n Member Posts: 9,256
    You have to check with MS. I would also test with your license.
    If you can run the W1 with your license, you should be set.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • IsakssonMiIsakssonMi Member Posts: 77
    Hello!

    It is a bug in Microsoft's Nav Stream class.

    In the void IStream.Read(byte[] buffer, int cb, IntPtr pcbRead) method, change the code to this:

    lock (this)
    {
    int bytesRead =0;
    if (cb!=0)
    {
    bytesRead = stream.Read(buffer, 0, cb);
    Marshal.WriteInt32(pcbRead, bytesRead);
    }
    if (pcbRead != IntPtr.Zero)
    Marshal.WriteInt32(pcbRead, bytesRead);
    }

    Or use the ToIStream-method which is found on blogs, which is much faster. That method uses unsafe code, bacause of that you should enable unsafe in your compiling settings.

    Good luck!

    Michael
  • jannavjannav Member Posts: 15
    IsakssonMi wrote:
    Hello!

    It is a bug in Microsoft's Nav Stream class.

    In the void IStream.Read(byte[] buffer, int cb, IntPtr pcbRead) method, change the code to this:

    lock (this)
    {
    int bytesRead =0;
    if (cb!=0)
    {
    bytesRead = stream.Read(buffer, 0, cb);
    Marshal.WriteInt32(pcbRead, bytesRead);
    }
    if (pcbRead != IntPtr.Zero)
    Marshal.WriteInt32(pcbRead, bytesRead);
    }

    Or use the ToIStream-method which is found on blogs, which is much faster. That method uses unsafe code, bacause of that you should enable unsafe in your compiling settings.

    Good luck!

    Michael

    Wow, you just saved my day! Thank you for posting this Michael.

    Could I ask you where and how you found this out? Is this only needed in Navision 4 or also in later versions?

    Last question is about the ToIstream. Is this really faster? Are we talking 100ms or more?
  • IsakssonMiIsakssonMi Member Posts: 77
    I don't remember how much faster, but I remember that I tested to animate something on a picturebox in a NAV-form by sending images by a COM-component with streams and I found out that ToIStream made the rendering a lot faster.

    And I guess using unsafe code is not a problem here, it only prevents the garbage collector to clean up memory and don't think memory leaks would occur in an example like this.

    I found out this by asking Microsoft when I had a byte limit bug.

    This is not a NAV bug, so this affects all versions of NAV.
  • jannavjannav Member Posts: 15
    And thank you for this extra information. I had an incoming xml, with a length of 65500 and couldn't understand it. Most of the time the xml had a length of 2000. Had no problems running it for some days now.. :)
Sign In or Register to comment.