Hi Guys,

As many of you will know I’ve been building up a video library that is designed to provide you with a relatively quick overview of certain Revelation topics. Recent postings have included WebOI, Bravo Dashboard and RevDotNet. I have another video planned and scripted that runs through the new features in OI 9.x and I hope to have that one finished sometime very soon.

I have been running a poll on my blog (http://www.revsoftuk.blogspot.com/) to try to gauge the usefulness of these videos and how many of you actually look at them. At the present time the poll figures are very low, indicating that the large amount of time taken to put the videos together is not worthwhile.

Please take a few minutes to review the videos on my YouTube channel (http://www.youtube.com/user/revsoftuk) and then vote on my blog poll to let me know whether I should continue or drop the videos down my list of priorities.

The poll closes tomorrow, so please vote today to register your interest in keeping the videos coming.

Thanks,

M.

Martyn,

I just voted on the blog. For what it's worth, I've only viewed one of the videos…just enough to see that you are doing an exemplary job and I greatly appreciate it. The value for me is that they are there *when* I need them. The primary issue for me is that very few clients are moving into 9.x due to the licensing changes.

[email protected]

SRP Computer Solutions, Inc.

Hey Martyn,

Let me also say that I appreciate your videos and believe that they add value to the product provided. However, sometimes I feel like I'm missing things, but I will echo what Don said. I thought that I was alone. In my case, we're still at OI 7.2.2.

1) I would like to move up, but I'm not sure how I can move me and my clients to OI 9.x in a way that would work. I prefer not having two code sets one for us with OI 9.x and with some of our clients stuck at OI 7.2x.

2) We can perhaps modified our support agreement with our clients to reflect the licensing changes, but our clients' anniversary date varies and I can't eat the extra costs for all so we can all be in synch and I can't afford to be burden with two sets of codes. (Heck I had enough problem with our recent RDK. I will give my solution later.)

3) Plus, the upgrade process would be a pain for us (7.2.2 -] 8.0x -] 9.0x) Wish this could be easier.

Does anyone have a suggestion or comment on #1 and #2 above? RTI?

Going back to Martyn post, thanks for your contributions. Again, I really do appreciate them. I think that they are super and again really add to the value of OI. Keep up the good work Martyn and RevUK.

Ray Chan

Ray,

Wrt to the upgrade process it is possible to upgrade from say 7.22 to 8.0x in one hit (actually from 4.x thru to 8.06). Indeed I have been working thru one developer's client base doing a migration from 4.13 to 8.08 and the upgrade process per se has been quick and straightforward. I'm sure that Rev could create a 7.x to 9.1 if there was a real demand.

Richard Bright

BrightIdeas NZ

Hi Richard,

Good to hear from you. If RTI made an upgrade from 7.x to 9.1, that would be great. Why does there have to be a demand? Just do it. Why make it hard for the clients.

Any case, doing the upgrade is no fun. The last upgrade I did was 7.01 to 7.1 to 7.11 to 7.2 to 7.21. So I should be glad that I can now just jump from 7.2.2 to 8.06. I'm assuming that from there we can then go to 9.xx.

My major concerns are really the first and second issues that I raised earlier. How do I upgrade my clients without having to maintain two set of codes. Even if all my clients cover the extra licensing fee, my clients all don't have the same due date. This again means I'm stuck with supporting two sets of code for some months which I'm not ready to do. This should probably be a separate Subject. The original intent was to Thanks Martyn for his extra effort in helping us developer with his Video Tutorial, but because most of these tutorials are OI9 stuff they don't mean that much to mean, but I would like to think that somehow and sometime I can make this transition. But I need help with this dilemma. I want to move to OI9, but don't want to maintain two code set for some months. I could upgrade all my clients to OI 9.xx, but I can't afford to pay for all of them.

Hey let me give Martyn another shoutout: I hope you keep them coming because I do view your videos.

Ray Chan

Hi Richard,

Good to hear from you. If RTI made an upgrade from 7.x to 9.1, that would be great. Why does there have to be a demand? Just do it. Why make it hard for the clients.

Any case, doing the upgrade is no fun. The last upgrade I did was 7.01 to 7.1 to 7.11 to 7.2 to 7.21. So I should be glad that I can now just jump from 7.2.2 to 8.06. I'm assuming that from there we can then go to 9.xx.

My major concerns are really the first and second issues that I raised earlier. How do I upgrade my clients without having to maintain two set of codes. Even if all my clients cover the extra licensing fee, my clients all don't have the same due date. This again means I'm stuck with supporting two sets of code for some months which I'm not ready to do. This should probably be a separate Subject. The original intent was to Thanks Martyn for his extra effort in helping us developer with his Video Tutorial, but because most of these tutorials are OI9 stuff they don't mean that much to mean, but I would like to think that somehow and sometime I can make this transition. But I need help with this dilemma. I want to move to OI9, but don't want to maintain two code set for some months. I could upgrade all my clients to OI 9.xx, but I can't afford to pay for all of them.

Hey let me give Martyn another shoutout: I hope you keep them coming because I do view your videos.

Ray Chan

In Rev's defense they have been willing to supply scripts that will upgrade from 4.1.x to 8.0. However, unless things have changed, that's as far as it can get without the authorization code requirement. Herein lies a different challenge to upgrading (i.e. separate from the licensing changes.) Upgrading apps in the field without manual intervention by the developer, especially for commercial apps, is rather difficult.

[email protected]

SRP Computer Solutions, Inc.

Upgrading as labor as intensive as it may be is not the killer at the momement. It's the licensing thing as I tried to describe in my situation at least.

Ho hum. Hey is it 4.x to 8.0 or to 8.06?

Hi, Martyn.

I just discovered your stuff today. I happened to look at the 'Support' area. I usually only look in Works.

Anyhow, just started looking at your videos, and they are great!

Plan to spend some time today checking them all out.

Hope you feel like continuing, I guess it can be a bit of a thankless task at times.

Have fun,

Paxton

The one I was referring to was all the way to 8.0.6 in one easy jump. Yes this does require an authorisation code - but this isnt a big impediment.

Interestingly, we have the decision process; do we upgrade all our clients 'in situe' or do we upgrade the engines and re-deploy using new client master system and re-integrate the client-live properties. The merit of the latter approach is to get rid of all the rubish and potential corruption that could have accumulated over a period of time - bit like refreshing Windows o/s once in a while. Of cause this option is only available if the application architecture is sufficiently discrete and can be separated from the Rev base system ie AppLivedatavol, AppClientEnvironment tables etc.

Richard Bright

View this thread on the forum...