sage 300 SDK vs sage 50 sdk - how different?

SOLVED

I been developing software for sage 50 using the sage 50 SDK along with .net.

 

The software is built in .net and allows me to easy push out invoices from .net. In fact I build the app as a “com” object, and thus the resulting object works with office. So Excel, or in this case MS Access or any office program can create and then push out invoices to Sage 50 rather easy. And so can our software solution we sell to our clients.

So the SDK kit and the .net interface was rather nice, and was rather easy to get up and running with. And I did not have to sign up for anything. A google gave the url to download the current version of the SDK, and I was off to the races.

 Downloaded a trial version of Sage – and boom! – Client was happy.

And every 6 months or whatever, I just hit the sdk download page, download, re-compile, and again the client is happy. (wish the version numbers were not so tightly matched, but really, nothing we not been able to deal with).

I have some clients reaching the point in which they want (need to) jump from sage 50 to sage 300. I have told these existing clients to NOT upgrade until we make a decision. So due to developer constraints (limited time), we not yet created a sage 300 interface for our software.

 So a few simple questions here:

How close is the SDK for sage 50 to that of sage 300? (the .net one). In other words, a interface built in .net for sage 50, how much of this transfers over to the sage 300 SDK? (how similar).

I don’t see a forum in this 300 area for the SDK like I do for the sage 50 forms? Is there a reason for this?

And the last whopper:

Why can’t I just land on some page with SDK info? Why does this process have to be so difficult? The download, adopting and finding the sage 50 sdk was a breeze (my fault for assuming that the rest of sage products would be this easy to get up and running with).

 Anyway, any help, and comments from “how” hard the change over from sage 50 sdk to 300 sdk is “most” valuable info since I trying to come up with the amounts of time I need to allocate for this transition to sage 300.

 Thanks in advance.

 

Regards,

Albert D. Kallal

Edmonton, Alberta Canada

  • +1
    verified answer

    Sage has always kept the 300 SDK tight to the vest, you have to sign up and pay for it separately.  After 18 years of doing 300 development I've never actually used the SDK to compile my own app, I rely on its COMAPI to compile with VB6, VBDotNet, and C#DotNet, Excel, or Access.

  • 0 in reply to Jay Converse Acumen
    SUGGESTED

    Oh, gee - Thank you so kindly!

    Ok, so sage 300 (I guess at one time Acc pak) is available as a “com” application.

     Ok, then that quite much means “little” reason or need for the SDK as you point out.

    What great simple answer! So to anyone reading this, likely not a whole lot of info and stuff for the 300 SDK because FEW if any developers really much need a SDK with sage 300.

    In other words.

    The sage 300 system out of the box allows automation (COM/ActiveX) interface. As a result no other SDK packages and the like is required here.

    Thanks for a short, sweet and great answer that clears up near everything to everyone!!!!!

     This much suggests that I can go for a trial edition of sage 300, or at least get a client location to install a copy without registering for me to test code.

    Again, thank you!

    Regards,

    Albert D. Kallal

    Edmonton, Alberta Canada