I sometimes wonder how many developers actually make any money out of having a Line 50 Developers licence.
Had another call today from a user who has an SDO v10 application. They've just upgraded to v12 and it has not surprisinly stopped working. The developer flatly refuses to pay for a V12 licence, presumably because they can't make any money out of it and undoubtedly the user doesn't want to pay a realistic amount. Were not about to do the job for 3/6 either. We have had this experience a number of times so it can't be uncommon.
The problem is that Line 50 is relatively cheap so the users perception of everything else is that it should be similarly cheap. Strangely, I don't think the answer is to make the SDO licence cheaper as this would just mean there is absolutely no money in developing for Sage Line 50 at all. Perhaps developers should try charging a sensible rate for their work instead of following the rest of the computer industry down the plughole of ever decreasing prices.
Speaking as someone with other 30 years in the industry and experience of just about every role, development is a lot more time consuming than installing a server and requires a far more expensive set of tools ; Sage Licence, Sage Additions advertising, Programming languag, MSDN subscription etc but I can still make far more money slapping in a server than spending a lot more time developing a robust piece of code.
Tuesday, September 19, 2006
Thursday, September 14, 2006
Sage Line 50 Version 13 (sorry 2007)
We got our copies of the new Sage Line 50 and the developers toolkit today.
Initial impressions are that Line 50 looks pretty much the same as version 12 in terms of the interface.
We will be starting to test the new sdo with our products in the next few days so watch this space.
Initial impressions are that Line 50 looks pretty much the same as version 12 in terms of the interface.
We will be starting to test the new sdo with our products in the next few days so watch this space.
Tuesday, August 29, 2006
Sage Line 50 : Quick, Quick, Slow?
Performance seems to be a common problem in Sage Line 50.
I think it's fair to say that some operations are slow, particularly when there are lots of transactions on the system, but equally I'm not convinced, unlike some commentators, that network configuration is not a significant factor. It's also kind of interesting to compare Sage running on an old Win98 box and an all singing and dancing XP box accessing data files on the same server.
It's quite possible that Sage haven't taken the time to test some of the issues in a controlled environment, but we have and significant performance gains are available for relatively little effort.
For example, using a unc path to the Sage data files rather than a mapped drive letter can reduce performance by 50%.
Similiarly Norton AV on the Sage dta files will grind Sage to a halt.
Turn off Opportunistic Locking on the client or server. There are lots of Microsoft Knowledge Base Articles on this subject.
There are another couple of Windows Server Policy settings that have dramatic effects on scrolling through lists of Invoices for example and the speed of reporting but I'm not going to list them here because a) We need to make a living and b) You run the risk of messing up your system if you don't know what you are doing.
You will still need to extract data for some operations because, yes, Sage uses an old architecture and some fields aren't indexed
I think it's fair to say that some operations are slow, particularly when there are lots of transactions on the system, but equally I'm not convinced, unlike some commentators, that network configuration is not a significant factor. It's also kind of interesting to compare Sage running on an old Win98 box and an all singing and dancing XP box accessing data files on the same server.
It's quite possible that Sage haven't taken the time to test some of the issues in a controlled environment, but we have and significant performance gains are available for relatively little effort.
For example, using a unc path to the Sage data files rather than a mapped drive letter can reduce performance by 50%.
Similiarly Norton AV on the Sage dta files will grind Sage to a halt.
Turn off Opportunistic Locking on the client or server. There are lots of Microsoft Knowledge Base Articles on this subject.
There are another couple of Windows Server Policy settings that have dramatic effects on scrolling through lists of Invoices for example and the speed of reporting but I'm not going to list them here because a) We need to make a living and b) You run the risk of messing up your system if you don't know what you are doing.
You will still need to extract data for some operations because, yes, Sage uses an old architecture and some fields aren't indexed
Sage Line 50 Solution Selling
Having read a few Sage related blogs quite by accident I thought I might as well have a go myself.
A lot of the comment I have seen related to Line 50 seems to miss the basic point that all services / solutions related to a Sage sale (or anything else for that matter) are directly proportional to the price of the product being sold.
If someone buys a £5000 car they aren't going to expect (or pay) the sort of service bills you get for a £30,000 car. Exactly the same principle applies to the computer industry, so, if you want to make more money, start selling a more expensive solution.
A lot of the comment I have seen related to Line 50 seems to miss the basic point that all services / solutions related to a Sage sale (or anything else for that matter) are directly proportional to the price of the product being sold.
If someone buys a £5000 car they aren't going to expect (or pay) the sort of service bills you get for a £30,000 car. Exactly the same principle applies to the computer industry, so, if you want to make more money, start selling a more expensive solution.
Subscribe to:
Posts (Atom)
