cancel
Showing results for 
Search instead for 
Did you mean: 

Datawindow .net - End Of Life Notice

0 Kudos

Hi Community,

I want to know if there is a migration path for .net developers using Datawindow .net in their applications?

Is there some third party products in order to migrate the Datawindow .net functionality ?

Or after the "End Of Life Notice" all companies must migrate manually to another architecture, it is the only option?

 

Thanks in advance for your help.

Best Regards,

Douglas

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member190719
Active Contributor
0 Kudos
former_member190719
Active Contributor
0 Kudos

Well, although the EOL notice doesn't specify it, one option would be to move to PowerBuilder.Net.  One of the features added to version 12.5 was the ability to create visual custom user object assemblies using it that could them be used in Visual Studio projects.

I have a blog entry over in the PowerBuilder Developer Center which walks through the process of creating such assemblies, including the use of DataWindows within them.

0 Kudos

Hi Bruce!

For you with sure is the first time to hear about me, for me, is an honor to have an answer from you!!! I am a partner since Powersoft (later Sybase and now SAP!!), I was in every Techwave, I read a lot of interesting articles from you and learn a lot of things!

Regarding my question, our customer was a PB developers, however due to change in the CIO chair, they select .net to continue develop their applications, today they have critical applications in both environments but will be in the .net line, so they are asking us for a migration path in the .net environment due to lack of support in the datawindow .net, so they need to move their code to a new kind of data management in the .net arena, what is your opinion about that?

Thanks in advance.

Best Regards,

Douglas

former_member190719
Active Contributor
0 Kudos

Regarding my question, our customer was a PB developers, however due to change in the CIO chair, they select .net to continue develop their applications, today they have critical applications in both environments but will be in the .net line, so they are asking us for a migration path in the .net environment due to lack of support in the datawindow .net, so they need to move their code to a new kind of data management in the .net arena, what is your opinion about that?

The two questions I would ask about any migration are:

1.  What significant additional new features of the product are needed?

2.  What significant additoinal capability will be available as a result of the migration?

If the answer to both those questions is "none", I would question why the migration is needed.  If the application is stable (no additional new features need to be added) and if doing the migration doesn't result in some required capability that wasn't available before (e.g. ability to host on web or deploy to mobile devices) then why migrate?  Just let the app continue meeting the needs of existing customers and don't touch it.  It will eventually live out it's useful live and be replaced by something else, but I don't see the return on investment in migrating a stable app that doesn't add functionality or capability.

I think a lot of IT managers drastically underestimate the effort required to migrate an application as well as the chances of project failure.  The IT landscape is littered with failed migration projects that cost well in excess of their original projections, didn't meet the needs of the customers, and were eventually abandoned in favor of the original product.

Not to say that migration project always fail, I've worked on a few and they were successful.  However, the projects also focuses on providing just the core functionality, so the initial versions of the new software only did a portion of what the original application did.  It was more of a phased approach than an overnight conversion.  They were also projects in which the answers to the above questions were both yes.

If they still decide to go ahead with migration, the question is how much rewrite you want to do and how long you can allow it to take.  If you move to PowerBuilder.Net, you could probably still use large portions of the current code, and just make them accessible from a Visual Studio IDE.  If they want to take PowerBuilder out of the equation entirely, then you'll probably end up using a third party control and doing a lot more rewrite.  You'd also be assuming some of the same level of risk that it might not be supported in the future.

0 Kudos

Hi Bruce,

The main reason to search for a migration path, is due to lack of support in the near future, they are not thinking an overnight migration, they are preparing in what will happen when Microsoft release a new OS and Datawindow .Net is not supported in it for example, then they can stay stable until this happens.

And you have all the reason about the migrations are not easy, and they are not the exceptions, recently they acquire again the support of Powerbuiler in order to continue supporting their application still in Powerbuilder, in some way, they will stay here a couple of years more.

I want to confirm that I understand your last message, I know that they can generate a .net application using powerscript and datawindow, in your message you mention they can "probable still use large portions of the current code", from that comes the following questions:

1. Can Powerbuilder edit .net code not generated from Powerbuilder? Can edit code generated from Visual Studio? and using Datawindow .Net?

2. Can they use Powerbuilder to edit datawindows instead of the Datawindow .net program, of course for datawindows created from Datawindow .net?

3. There is no license restriction in Powerbuilder?

What I understand is if they have Powerbuilder again, they can solve partially something about this issue, but I am not clearly at all how to do that.

Best Regards,

Douglas

former_member190719
Active Contributor
0 Kudos

1. Can Powerbuilder edit .net code not generated from Powerbuilder? Can edit code generated from Visual Studio? and using Datawindow .Net?

PowerBuilder can't edit C# or VB.Net code, and you wouldn't edit PB.Net code from Visual Studio.  However, you can create .Net assemblies from PowerBuilder which Visual Studio can use, as well as create assemblies from Visual Studio that PowerBuilder can do.  Much the same that you can create assemblies in C# and then use them in Visual Basic.Net.  They are different languages, but they compile down to the same Common Intermediate Language.

2. Can they use Powerbuilder to edit datawindows instead of the Datawindow .net program, of course for datawindows created from Datawindow .net?

Yes.

3. There is no license restriction in Powerbuilder?

Correct.  The IDE is licensed.  There is no runtime restrictions on what is generated from it though.

0 Kudos

Hi Bruce!

Just to confirm if I understand all our conversation, I can summarize that they can continue using PB to mitigate the support issues in order to continue development using Datawindows, then they can generate assemblies that includes those Datawindows to use it in C# or VB.Net code, so they can continue using and leveraging Datawindows in their existing and new .net applications.

Best Regards,

Douglas

former_member190719
Active Contributor
0 Kudos

Exactly....you've got it.

0 Kudos

Hi Bruce,

Thank you very much for your help!

Best Regards,

Douglas

Former Member
0 Kudos

I know this is an older post, but I have a related question.  We have been using a hybrid solution to use datawindows in our C# code using the Sybase.PowerBuilder.DataWindow.Win.dll as a reference.  This allows us to reference datawindows built using PowerBuilder and has been a very good transition for our PB developers.  The C# projects we support are Web and Windows Services and we are currently required to run these as 32 bit processes because of this reference.  Just this week, we downloaded the PB 12.6 release in hopes that would provide us a 64 bit version of this DLL.  Based on my initial research, I have not found that to be the case. 

Do you know of any plan to provide 64 bit support for this DLL or is there another option?

Thanks.

John C. Adams

Lead Engineer

Primerica Financial Services

former_member190719
Active Contributor
0 Kudos

PowerBuilder.Net has had 64 bit (actually "Any CPU" support) since 12.5.1 was released.  If you make sure you use an ADO.Net driver (not a native driver) you should be able to create a 64 bit build.

Former Member
0 Kudos

Agreed and I'm actually using that for a PB target that I'm compiling as a .Net assembly.  That seems to work.  The problem I'm having is with the C# web service attempting to use the Sybase.DataWindow.Win assembly.  The web service works as expected when we set IIS to allow 32 bit processes.  However, if I change the settings in IIS to not allow 32 bit processes, I receive the following error: 

"Could not load file or assembly 'Sybase.PowerBuilder.DataWindow.Win' or one of its dependencies. An attempt was made to load a program with an incorrect format."

Thanks.

former_member190719
Active Contributor
0 Kudos

All I can suggest is using Process Monitor or the Assembly Binding Log Viewer to see what it's trying to load that is causing the issue.

Former Member
0 Kudos

Hi Bruce - The EOL notice link goes straight to the start page for SAP.com. I have a US Department of the Treasury (DoT) customer who is looking for that. I have done an extensive Google search and am unable to locate it anywhere. Would you know how to find this document? Thanks, Mark

former_member190719
Active Contributor
0 Kudos

All I can suggest, provided you have a support agreement, is to check the SAP Product Availablity Matrix. ( I don't have a support agreement, so I can't verify one way or another whether it is included there ).

The Component Source web site ( a company that used to sell the product) refers the same document and indicates that the end of engineering support occurred on April 1st, 2012.  Perhaps that would help.

Former Member
0 Kudos

Hi Bruce... I don't think they will found any information there about datawindow.net. Datawindow.net was EOL before the merge began... It's not listed as a product...

Andreas.

CobyKako
Advisor
Advisor
0 Kudos

I confirm Andreas: Sybase DataWindow .NET was never listed in the PAM (Product Availability Matrix) web site

Jacob