I have a large app that I've migrated to PB .Net 12.1 build
6639.  It takes 1.5 + hours to build.

Every time I make a modification then attempt to run it
wants to build - which takes forever.  (2135 .cs files, 882
xaml files, 1128 dws)

Is there any setting that I'm missing that will reduce this
pain?

thanks
Deanne

Deanne,

Unfortunately, I don't know of a magic formula.  Even an 'incremental' 
build is time consuming.  There is a radical difference between the 
platforms and build mechanisms.

The only way around that I see is to refactor your code into autonomous 
assemblies that can be built separately.  No small task but one that 
will pay dividends at build time.  Watch my demo at 
http://www.youtube.com/watch?v=mYKI34xy6Ew to get an idea of the process

Bye Bye RAD, Hello Unit Testing

-- 
Yakov
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com

On 1/10/2011 12:38 PM, Deanne wrote:
> I have a large app that I've migrated to PB .Net 12.1 build
> 6639.  It takes 1.5 + hours to build.
>
> Every time I make a modification then attempt to run it
> wants to build - which takes forever.  (2135 .cs files, 882
> xaml files, 1128 dws)
>
> Is there any setting that I'm missing that will reduce this
> pain?
>
> thanks
> Deanne

Hi Deanne;

   There is hope on the horizon in PB 12.5 as PB will allow you to build one 
assembly per PBL (or combination of PBls). This means that PB.Net will only 
be required to recompile the PBL (assembly where you made the change). I 
would think that this will save an enormous amount of time compared to 
todays full build approach - especially for a large application.

  Now there is an EBF due out some time soon that may also address this by 
compiling a select set of assemblies per PBL. I have not seen either 
mechanism yet so I can not comment on how much better the compile times 
might be under either of these schemes compared to what you are encountering 
today.

Regards ... Chris
President: OSUG / STD Inc.
Blog: http://chrispollach.blogspot.com
PBDJ: http://chrispollach.sys-con.com
SourceForge: http://sourceforge.net/projects/stdfndclass

"Deanne" wrote in message news:4d2b4419.2c62.1681692777@sybase.com...

I have a large app that I've migrated to PB .Net 12.1 build
6639.  It takes 1.5 + hours to build.

Every time I make a modification then attempt to run it
wants to build - which takes forever.  (2135 .cs files, 882
xaml files, 1128 dws)

Is there any setting that I'm missing that will reduce this
pain?

thanks
Deanne 

Hi Deanne;

  Note: With Yakov's "assembly" suggestion you cannot use DataWindow 
pointers (or any PB objects for that matter) - so if your application passes 
DW Controls or DataStores around by reference, this approach could end up 
being quite a challenge to implement. You also cannot share a DB connection 
(aka pass SQLCA pointer around), etc. So if your application does many of 
these types of things - assemblies may not be an option for you.

Regards ... Chris
President: OSUG / STD Inc.
Blog: http://chrispollach.blogspot.com
PBDJ: http://chrispollach.sys-con.com
SourceForge: http://sourceforge.net/projects/stdfndclass

"Yakov Werde"  wrote in message news:4d2b4f55$1@forums-1-dub...

Deanne,

Unfortunately, I don't know of a magic formula.  Even an 'incremental'
build is time consuming.  There is a radical difference between the
platforms and build mechanisms.

The only way around that I see is to refactor your code into autonomous
assemblies that can be built separately.  No small task but one that
will pay dividends at build time.  Watch my demo at
http://www.youtube.com/watch?v=mYKI34xy6Ew to get an idea of the process

Bye Bye RAD, Hello Unit Testing

-- 
Yakov
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com

On 1/10/2011 12:38 PM, Deanne wrote:
> I have a large app that I've migrated to PB .Net 12.1 build
> 6639.  It takes 1.5 + hours to build.
>
> Every time I make a modification then attempt to run it
> wants to build - which takes forever.  (2135 .cs files, 882
> xaml files, 1128 dws)
>
> Is there any setting that I'm missing that will reduce this
> pain?
>
> thanks
> Deanne 

Actually, Chris, with an ADO.NET driver it is possible to pass a 
connection around.  The transaction object has two additional methods 
GetADOConnection( ) and SetADOConnection(  ).  See the .NET Features 
Guide --> Database Management in PowerBuilder.NET --> Sharing an ADO.NET 
Database Connection for an illustration and explanation.

-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com


On 1/10/2011 9:07 PM, Chris Pollach wrote:
> Hi Deanne;
>
> Note: With Yakov's "assembly" suggestion you cannot use DataWindow
> pointers (or any PB objects for that matter) - so if your application
> passes DW Controls or DataStores around by reference, this approach
> could end up being quite a challenge to implement. You also cannot share
> a DB connection (aka pass SQLCA pointer around), etc. So if your
> application does many of these types of things - assemblies may not be
> an option for you.
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "Yakov Werde" wrote in message news:4d2b4f55$1@forums-1-dub...
>
> Deanne,
>
> Unfortunately, I don't know of a magic formula. Even an 'incremental'
> build is time consuming. There is a radical difference between the
> platforms and build mechanisms.
>
> The only way around that I see is to refactor your code into autonomous
> assemblies that can be built separately. No small task but one that
> will pay dividends at build time. Watch my demo at
> http://www.youtube.com/watch?v=mYKI34xy6Ew to get an idea of the process
>
> Bye Bye RAD, Hello Unit Testing
>

Thanks ... Good to know if your environment supports ADO.net for your DBMS.


"Yakov Werde [TeamSybase]"  wrote in message news:4d2bc928$1@forums-1-dub...


Actually, Chris, with an ADO.NET driver it is possible to pass a
connection around.  The transaction object has two additional methods
GetADOConnection( ) and SetADOConnection(  ).  See the .NET Features
Guide --> Database Management in PowerBuilder.NET --> Sharing an ADO.NET
Database Connection for an illustration and explanation.

-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com


On 1/10/2011 9:07 PM, Chris Pollach wrote:
> Hi Deanne;
>
> Note: With Yakov's "assembly" suggestion you cannot use DataWindow
> pointers (or any PB objects for that matter) - so if your application
> passes DW Controls or DataStores around by reference, this approach
> could end up being quite a challenge to implement. You also cannot share
> a DB connection (aka pass SQLCA pointer around), etc. So if your
> application does many of these types of things - assemblies may not be
> an option for you.
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "Yakov Werde" wrote in message news:4d2b4f55$1@forums-1-dub...
>
> Deanne,
>
> Unfortunately, I don't know of a magic formula. Even an 'incremental'
> build is time consuming. There is a radical difference between the
> platforms and build mechanisms.
>
> The only way around that I see is to refactor your code into autonomous
> assemblies that can be built separately. No small task but one that
> will pay dividends at build time. Watch my demo at
> http://www.youtube.com/watch?v=mYKI34xy6Ew to get an idea of the process
>
> Bye Bye RAD, Hello Unit Testing
> 

On 1/10/2011 10:32 PM, Chris Pollach wrote:
> Thanks ... Good to know if your environment supports ADO.net for your DBMS.
>
>
> "Yakov Werde [TeamSybase]" wrote in message news:4d2bc928$1@forums-1-dub...
>
>
> Actually, Chris, with an ADO.NET driver it is possible to pass a
> connection around. The transaction object has two additional methods
> GetADOConnection( ) and SetADOConnection( ). See the .NET Features
> Guide --> Database Management in PowerBuilder.NET --> Sharing an ADO.NET
> Database Connection for an illustration and explanation.
>

Could you list those dbms' for which there are no ADO drivers

-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com

The last word is that an EBF due in February will give the ability to 
create separate assemblies by library similar to how PB Classic works. 
It will have the additional ability to group multiple libraries into one 
assembly.

On 1/10/2011 7:47 PM, Chris Pollach wrote:
> Hi Deanne;
>
>   There is hope on the horizon in PB 12.5 as PB will allow you to 
> build one assembly per PBL (or combination of PBls). This means that 
> PB.Net will only be required to recompile the PBL (assembly where you 
> made the change). I would think that this will save an enormous amount 
> of time compared to todays full build approach - especially for a 
> large application.
>
>  Now there is an EBF due out some time soon that may also address this 
> by compiling a select set of assemblies per PBL. I have not seen 
> either mechanism yet so I can not comment on how much better the 
> compile times might be under either of these schemes compared to what 
> you are encountering today.
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "Deanne" wrote in message news:4d2b4419.2c62.1681692777@sybase.com...
>
> I have a large app that I've migrated to PB .Net 12.1 build
> 6639.  It takes 1.5 + hours to build.
>
> Every time I make a modification then attempt to run it
> wants to build - which takes forever.  (2135 .cs files, 882
> xaml files, 1128 dws)
>
> Is there any setting that I'm missing that will reduce this
> pain?
>
> thanks
> Deanne

    Its not only whether there is an ADO.net driver for your DBMS & 
versions - but, more importantly if your technical environment and technical 
support people will allow the ADO.net connectivity to be installed on the 
end users desktop machines. In the Canadian government for example most 
departments client machines are locked down. Also, many DBA areas dictate 
the connectivity - for example in Oracle its pretty much OCI.  So it may 
boil down to local policies.

   Now, if you are converting from a native driver, OLE-DB, ODBC, etc to 
ADO.Net you would still have to a) change the way SQLCA is called; b) add 
extra ADO.Net function calls; c) tweak your SQL for ADO.net, d) check for 
performance problems, e) check/resolve DML & result set functionality issues 
and (of course) d) test the living daylights out of your application. So 
when you think about the entire process of switching to ADO.net - it should 
not be taken lightly IMHO

Just my $0.02 on the other side of the coin.



"Yakov Werde [TeamSybase]"  wrote in message news:4d2c601a$1@forums-1-dub...

On 1/10/2011 10:32 PM, Chris Pollach wrote:
> Thanks ... Good to know if your environment supports ADO.net for your 
> DBMS.
>
>
> "Yakov Werde [TeamSybase]" wrote in message 
> news:4d2bc928$1@forums-1-dub...
>
>
> Actually, Chris, with an ADO.NET driver it is possible to pass a
> connection around. The transaction object has two additional methods
> GetADOConnection( ) and SetADOConnection( ). See the .NET Features
> Guide --> Database Management in PowerBuilder.NET --> Sharing an ADO.NET
> Database Connection for an illustration and explanation.
>

Could you list those dbms' for which there are no ADO drivers

-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com 

Hi Roland;

    Thanks for that tip - I had heard that as well.

    Now this brings up a question in my mind as when you build an assembly 
today and include this in another PB application you *cannot* pass PB object 
references between your application and the Assembly. Will the PBL/Assembly 
feature in the next EBF and the approach  proposed in PB 12.5 also be bound 
by this restriction (like we have today in PB 12.1)?

Regards ... Chris
President: OSUG / STD Inc.
Blog: http://chrispollach.blogspot.com
PBDJ: http://chrispollach.sys-con.com
SourceForge: http://sourceforge.net/projects/stdfndclass

"Roland Smith [TeamSybase]"  wrote in message 
news:4d2c70ac$1@forums-1-dub...

The last word is that an EBF due in February will give the ability to
create separate assemblies by library similar to how PB Classic works.
It will have the additional ability to group multiple libraries into one
assembly.

On 1/10/2011 7:47 PM, Chris Pollach wrote:
> Hi Deanne;
>
>   There is hope on the horizon in PB 12.5 as PB will allow you to build 
> one assembly per PBL (or combination of PBls). This means that PB.Net will 
> only be required to recompile the PBL (assembly where you made the 
> change). I would think that this will save an enormous amount of time 
> compared to todays full build approach - especially for a large 
> application.
>
>  Now there is an EBF due out some time soon that may also address this by 
> compiling a select set of assemblies per PBL. I have not seen either 
> mechanism yet so I can not comment on how much better the compile times 
> might be under either of these schemes compared to what you are 
> encountering today.
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "Deanne" wrote in message news:4d2b4419.2c62.1681692777@sybase.com...
>
> I have a large app that I've migrated to PB .Net 12.1 build
> 6639.  It takes 1.5 + hours to build.
>
> Every time I make a modification then attempt to run it
> wants to build - which takes forever.  (2135 .cs files, 882
> xaml files, 1128 dws)
>
> Is there any setting that I'm missing that will reduce this
> pain?
>
> thanks
> Deanne 

Yakov, Chris,
You have both raised some good points.  I have "inherited"
this code and it is obvious to me that the app has
"technical debt" associated with it.  New features have been
added, but obsoleted objects have not been removed; there is
no separation between the gui and the business layer etc.

Unfortunately, the nvos that exist have multiple functions
that use pb components as parameters; as well a significant
amount of functionality exists in global functions - so I'm
not sure how much "bang for the buck" I'd get moving stuff
the existing stuff to assemblies.

I have already indicated to management that they will soon
start to "pay the piper" for the  technical debt that exists
in the app.

Thanks for you input, and Yakov the video was great it
explained things beautifully.

Deanne

> On 1/10/2011 10:32 PM, Chris Pollach wrote:
> > Thanks ... Good to know if your environment supports
> ADO.net for your DBMS. >
> >
> > "Yakov Werde [TeamSybase]" wrote in message
> news:4d2bc928$1@forums-1-dub... >
> >
> > Actually, Chris, with an ADO.NET driver it is possible
> > to pass a connection around. The transaction object has
> > two additional methods GetADOConnection( ) and
> > SetADOConnection( ). See the .NET Features Guide -->
> Database Management in PowerBuilder.NET --> Sharing an
> > ADO.NET Database Connection for an illustration and
> explanation. >
>
> Could you list those dbms' for which there are no ADO
> drivers
>
> --
> Yakov [TeamSybase]
> eLearnIT LLC
> Twitter: http://twitter.com/eLearnPB
> Blog: http://yakovwerde.sys-con.com
> Web Site: http://www.eLearnITOnline.com

Hi Deanne;

   You are most welcome ... and, I also feel your pain (been there done 
that).

Good luck with the application!

Regards ... Chris
President: OSUG / STD Inc.
Blog: http://chrispollach.blogspot.com
PBDJ: http://chrispollach.sys-con.com
SourceForge: http://sourceforge.net/projects/stdfndclass

"Deanne" wrote in message news:4d2c7e32.7675.1681692777@sybase.com...

Yakov, Chris,
You have both raised some good points.  I have "inherited"
this code and it is obvious to me that the app has
"technical debt" associated with it.  New features have been
added, but obsoleted objects have not been removed; there is
no separation between the gui and the business layer etc.

Unfortunately, the nvos that exist have multiple functions
that use pb components as parameters; as well a significant
amount of functionality exists in global functions - so I'm
not sure how much "bang for the buck" I'd get moving stuff
the existing stuff to assemblies.

I have already indicated to management that they will soon
start to "pay the piper" for the  technical debt that exists
in the app.

Thanks for you input, and Yakov the video was great it
explained things beautifully.

Deanne

> On 1/10/2011 10:32 PM, Chris Pollach wrote:
> > Thanks ... Good to know if your environment supports
> ADO.net for your DBMS. >
> >
> > "Yakov Werde [TeamSybase]" wrote in message
> news:4d2bc928$1@forums-1-dub... >
> >
> > Actually, Chris, with an ADO.NET driver it is possible
> > to pass a connection around. The transaction object has
> > two additional methods GetADOConnection( ) and
> > SetADOConnection( ). See the .NET Features Guide -->
> Database Management in PowerBuilder.NET --> Sharing an
> > ADO.NET Database Connection for an illustration and
> explanation. >
>
> Could you list those dbms' for which there are no ADO
> drivers
>
> --
> Yakov [TeamSybase]
> eLearnIT LLC
> Twitter: http://twitter.com/eLearnPB
> Blog: http://yakovwerde.sys-con.com
> Web Site: http://www.eLearnITOnline.com 

It is my understanding that the Assemblies automatically built by the 
12.1 EBF tool will NOT be CLS compliant. They will only be callable from 
PowerScript .NET application. In addition to providing automatic 
assembly generation this restriction will allow the passing of 
PowerScript types in method invocations.  The contents of these 
assemblies will NOT be callable from non PowerBuilder code.

Yakov

On 1/11/2011 10:25 AM, Chris Pollach wrote:
> Hi Roland;
>
> Thanks for that tip - I had heard that as well.
>
> Now this brings up a question in my mind as when you build an assembly
> today and include this in another PB application you *cannot* pass PB
> object references between your application and the Assembly. Will the
> PBL/Assembly feature in the next EBF and the approach proposed in PB
> 12.5 also be bound by this restriction (like we have today in PB 12.1)?
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "Roland Smith [TeamSybase]" wrote in message
> news:4d2c70ac$1@forums-1-dub...
>
> The last word is that an EBF due in February will give the ability to
> create separate assemblies by library similar to how PB Classic works.
> It will have the additional ability to group multiple libraries into one
> assembly.
>
> On 1/10/2011 7:47 PM, Chris Pollach wrote:
>> Hi Deanne;
>>
>> There is hope on the horizon in PB 12.5 as PB will allow you to build
>> one assembly per PBL (or combination of PBls). This means that PB.Net
>> will only be required to recompile the PBL (assembly where you made
>> the change). I would think that this will save an enormous amount of
>> time compared to todays full build approach - especially for a large
>> application.
>>
>> Now there is an EBF due out some time soon that may also address this
>> by compiling a select set of assemblies per PBL. I have not seen
>> either mechanism yet so I can not comment on how much better the
>> compile times might be under either of these schemes compared to what
>> you are encountering today.
>>
>> Regards ... Chris
>> President: OSUG / STD Inc.
>> Blog: http://chrispollach.blogspot.com
>> PBDJ: http://chrispollach.sys-con.com
>> SourceForge: http://sourceforge.net/projects/stdfndclass
>>
>> "Deanne" wrote in message news:4d2b4419.2c62.1681692777@sybase.com...
>>
>> I have a large app that I've migrated to PB .Net 12.1 build
>> 6639. It takes 1.5 + hours to build.
>>
>> Every time I make a modification then attempt to run it
>> wants to build - which takes forever. (2135 .cs files, 882
>> xaml files, 1128 dws)
>>
>> Is there any setting that I'm missing that will reduce this
>> pain?
>>
>> thanks
>> Deanne
>

Hi Yakov;

   If they are not CLS compliant, will there be other limitations such as 
"marked as non-manageable code" for example?

Regards ... Chris



"Yakov Werde [TeamSybase]"  wrote in message news:4d2c82d2$1@forums-1-dub...


It is my understanding that the Assemblies automatically built by the
12.1 EBF tool will NOT be CLS compliant. They will only be callable from
PowerScript .NET application. In addition to providing automatic
assembly generation this restriction will allow the passing of
PowerScript types in method invocations.  The contents of these
assemblies will NOT be callable from non PowerBuilder code.

Yakov

On 1/11/2011 10:25 AM, Chris Pollach wrote:
> Hi Roland;
>
> Thanks for that tip - I had heard that as well.
>
> Now this brings up a question in my mind as when you build an assembly
> today and include this in another PB application you *cannot* pass PB
> object references between your application and the Assembly. Will the
> PBL/Assembly feature in the next EBF and the approach proposed in PB
> 12.5 also be bound by this restriction (like we have today in PB 12.1)?
>
> Regards ... Chris
> President: OSUG / STD Inc.
> Blog: http://chrispollach.blogspot.com
> PBDJ: http://chrispollach.sys-con.com
> SourceForge: http://sourceforge.net/projects/stdfndclass
>
> "Roland Smith [TeamSybase]" wrote in message
> news:4d2c70ac$1@forums-1-dub...
>
> The last word is that an EBF due in February will give the ability to
> create separate assemblies by library similar to how PB Classic works.
> It will have the additional ability to group multiple libraries into one
> assembly.
>
> On 1/10/2011 7:47 PM, Chris Pollach wrote:
>> Hi Deanne;
>>
>> There is hope on the horizon in PB 12.5 as PB will allow you to build
>> one assembly per PBL (or combination of PBls). This means that PB.Net
>> will only be required to recompile the PBL (assembly where you made
>> the change). I would think that this will save an enormous amount of
>> time compared to todays full build approach - especially for a large
>> application.
>>
>> Now there is an EBF due out some time soon that may also address this
>> by compiling a select set of assemblies per PBL. I have not seen
>> either mechanism yet so I can not comment on how much better the
>> compile times might be under either of these schemes compared to what
>> you are encountering today.
>>
>> Regards ... Chris
>> President: OSUG / STD Inc.
>> Blog: http://chrispollach.blogspot.com
>> PBDJ: http://chrispollach.sys-con.com
>> SourceForge: http://sourceforge.net/projects/stdfndclass
>>
>> "Deanne" wrote in message news:4d2b4419.2c62.1681692777@sybase.com...
>>
>> I have a large app that I've migrated to PB .Net 12.1 build
>> 6639. It takes 1.5 + hours to build.
>>
>> Every time I make a modification then attempt to run it
>> wants to build - which takes forever. (2135 .cs files, 882
>> xaml files, 1128 dws)
>>
>> Is there any setting that I'm missing that will reduce this
>> pain?
>>
>> thanks
>> Deanne
>

On 1/11/2011 11:29 AM, Chris Pollach wrote:
> marked as non-manageable code

If you mean Un-Managed code - Nothing generated by PB .NET is 
un-managed.  Everything is CIL and executes on the .NET runtime.

The difference is whether the types are 'private' or public. I.E. 
interoperable with code written in other .NET languages.  The rules of 
the CTS indicate that private language specific types are permitted

-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com

"Kool" ... thanks!

So its sounds like only the calling convections change then.





"Yakov Werde [TeamSybase]"  wrote in message news:4d2c953c$1@forums-1-dub...

On 1/11/2011 11:29 AM, Chris Pollach wrote:
> marked as non-manageable code

If you mean Un-Managed code - Nothing generated by PB .NET is
un-managed.  Everything is CIL and executes on the .NET runtime.

The difference is whether the types are 'private' or public. I.E.
interoperable with code written in other .NET languages.  The rules of
the CTS indicate that private language specific types are permitted

-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com 

Deanne,

FYI Global functions are not intrinsically problematic.  They are 
wrapped in function 'classes' in the generated code.  All long as calls 
are limited to the application or assembly in which they are defined, 
all is well and good.  The issue is that they can't automatically be 
exposed to be called in an assembly interface.  If there is a need for 
that exposure then refactoring will be in order.

Importantly IHMO Refactoring should be cast as an investment for the 
future, not repaying the debts of the past

Yakov

On 1/11/2011 10:58 AM, Deanne wrote:
> Yakov, Chris,
> You have both raised some good points.  I have "inherited"
> this code and it is obvious to me that the app has
> "technical debt" associated with it.  New features have been
> added, but obsoleted objects have not been removed; there is
> no separation between the gui and the business layer etc.
>
> Unfortunately, the nvos that exist have multiple functions
> that use pb components as parameters; as well a significant
> amount of functionality exists in global functions - so I'm
> not sure how much "bang for the buck" I'd get moving stuff
> the existing stuff to assemblies.
>
> I have already indicated to management that they will soon
> start to "pay the piper" for the  technical debt that exists
> in the app.
>
> Thanks for you input, and Yakov the video was great it
> explained things beautifully.
>
> Deanne
>
>> On 1/10/2011 10:32 PM, Chris Pollach wrote:
>>> Thanks ... Good to know if your environment supports
>> ADO.net for your DBMS.>
>>>
>>> "Yakov Werde [TeamSybase]" wrote in message
>> news:4d2bc928$1@forums-1-dub...>
>>>
>>> Actually, Chris, with an ADO.NET driver it is possible
>>> to pass a connection around. The transaction object has
>>> two additional methods GetADOConnection( ) and
>>> SetADOConnection( ). See the .NET Features Guide -->
>> Database Management in PowerBuilder.NET -->  Sharing an
>>> ADO.NET Database Connection for an illustration and
>> explanation.>
>>
>> Could you list those dbms' for which there are no ADO
>> drivers
>>
>> --
>> Yakov [TeamSybase]
>> eLearnIT LLC
>> Twitter: http://twitter.com/eLearnPB
>> Blog: http://yakovwerde.sys-con.com
>> Web Site: http://www.eLearnITOnline.com


-- 
Yakov [TeamSybase]
eLearnIT LLC
Twitter: http://twitter.com/eLearnPB
Blog: http://yakovwerde.sys-con.com
Web Site: http://www.eLearnITOnline.com

BTW: Why did you decide to migrate the application to .NET vs staying with 
PB 12 classic?


"Deanne" wrote in message news:4d2c7e32.7675.1681692777@sybase.com...

Yakov, Chris,
You have both raised some good points.  I have "inherited"
this code and it is obvious to me that the app has
"technical debt" associated with it.  New features have been
added, but obsoleted objects have not been removed; there is
no separation between the gui and the business layer etc.

Unfortunately, the nvos that exist have multiple functions
that use pb components as parameters; as well a significant
amount of functionality exists in global functions - so I'm
not sure how much "bang for the buck" I'd get moving stuff
the existing stuff to assemblies.

I have already indicated to management that they will soon
start to "pay the piper" for the  technical debt that exists
in the app.

Thanks for you input, and Yakov the video was great it
explained things beautifully.

Deanne

> On 1/10/2011 10:32 PM, Chris Pollach wrote:
> > Thanks ... Good to know if your environment supports
> ADO.net for your DBMS. >
> >
> > "Yakov Werde [TeamSybase]" wrote in message
> news:4d2bc928$1@forums-1-dub... >
> >
> > Actually, Chris, with an ADO.NET driver it is possible
> > to pass a connection around. The transaction object has
> > two additional methods GetADOConnection( ) and
> > SetADOConnection( ). See the .NET Features Guide -->
> Database Management in PowerBuilder.NET --> Sharing an
> > ADO.NET Database Connection for an illustration and
> explanation. >
>
> Could you list those dbms' for which there are no ADO
> drivers
>
> --
> Yakov [TeamSybase]
> eLearnIT LLC
> Twitter: http://twitter.com/eLearnPB
> Blog: http://yakovwerde.sys-con.com
> Web Site: http://www.eLearnITOnline.com