ActivePerl Migration Win 2003 Server to Win 2008 Server

Discussion in 'Perl Misc' started by Klaus, Aug 19, 2010.

  1. Klaus

    Klaus Guest

    Hello,

    I hope this post is not OT in c.l.p.m.

    I have got a couple of medium-sized (1000+ lines of code) of Perl
    programs (64 bits) running on Windows Server 2003, the perl version
    is:

    C:\>perl -v
    This is perl, v5.10.1 built for MSWin32-x64-multi-thread
    (with 2 registered patches, see perl -V for more detail)
    Binary build 1007 [291969] provided by ActiveState http://www.ActiveState.com
    Built Jan 27 2010 14:12:21

    I am using ADODB to connect to MSAccess databases, I read
    ActiveDirectory entries and I use StorageCentral to setup Storage
    quotas for 1000+ directories.

    Now I have to migrate Windows Server from 2003 to 2008.

    Before I embark on this adventure, I would ask for the wisdom of the
    perl user community:

    - Does anybody have experience with migrating perl programs from
    Windows Server 2003 to 2008 ?

    - Are there any pitfalls I need to be aware of ?

    - Do you recommend upgrading from perl 5.10 (x64) to the newer perl
    5.12 (x64) at the same time ?
     
    Klaus, Aug 19, 2010
    #1
    1. Advertising

  2. Klaus

    Dr.Ruud Guest

    Data::Alias

    Ben Morrow wrote:

    > For instance, I just upgraded to 5.12 and
    > found that Data::Alias no longer works and isn't likely to be fixed.


    I still have good hopes that it will be fixed. It is a real favorite
    module of mine. When used well, it saves you quite some CPU-cycles and
    memory.

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #2
    1. Advertising

  3. Klaus

    Klaus Guest

    On 19 août, 13:46, Ben Morrow <> wrote:
    > Quoth Klaus <>:
    > > I hope this post is not OT in c.l.p.m.

    >
    > Certainly not :).


    Thanks :)

    > > Now I have to migrate Windows Server from 2003 to 2008.


    > While the upgrade *should* be painless, IME it isn't always and you
    > should make sure to test everything properly with the new perl before
    > putting it into production. For instance, I just upgraded to 5.12 and
    > found that Data::Alias no longer works and isn't likely to be fixed.


    I am not using Data::Alias, but I have a couple of in-house modules
    that certainly push the limits of what is possible under Perl 5.10
    (x64) and Windows Server 2003.

    Your advice is very well taken, and I will test properly with Perl
    5.12 (x64) and Windows Server 2008.

    --
    Klaus
     
    Klaus, Aug 19, 2010
    #3
  4. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    Ben Morrow wrote:
    > Quoth "Dr.Ruud" <>:
    >> Ben Morrow wrote:


    >>> For instance, I just upgraded to 5.12 and
    >>> found that Data::Alias no longer works and isn't likely to be fixed.

    >> I still have good hopes that it will be fixed. It is a real favorite
    >> module of mine. When used well, it saves you quite some CPU-cycles and
    >> memory.

    >
    > I don't think so. It's only ever a syntactic convenience over using
    > references, it's just a really nice one.


    That's a lie! :)

    Data::Dumper does many things at compile time (so no ENTER/LEAVE
    overhead that other aliassing solutions need (like Lexical::Alias).

    And you can make all (or many) values of a (huge) hash be a single SV
    (undef, for example).

    It is/was a great module. It should be resurrected.

    Though the new ':=' operator is promising too.

    Data::Alias gives things like

    alias my %bar = %{ $foo->{ bar } };

    which will also set $foo->{ bar } to {} if it was undef.
    Etc.

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #4
  5. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    Dr.Ruud wrote:
    > Ben Morrow wrote:
    >> Quoth "Dr.Ruud" <>:
    >>> Ben Morrow wrote:

    >
    >>>> For instance, I just upgraded to 5.12 and
    >>>> found that Data::Alias no longer works and isn't likely to be fixed.
    >>> I still have good hopes that it will be fixed. It is a real favorite
    >>> module of mine. When used well, it saves you quite some CPU-cycles
    >>> and memory.

    >>
    >> I don't think so. It's only ever a syntactic convenience over using
    >> references, it's just a really nice one.

    >
    > That's a lie! :)
    >
    > Data::Dumper does many things at compile time (so no ENTER/LEAVE
    > overhead that other aliassing solutions need (like Lexical::Alias).
    >
    > And you can make all (or many) values of a (huge) hash be a single SV
    > (undef, for example).
    >
    > It is/was a great module. It should be resurrected.
    >
    > Though the new ':=' operator is promising too.
    >
    > Data::Alias gives things like
    >
    > alias my %bar = %{ $foo->{ bar } };
    >
    > which will also set $foo->{ bar } to {} if it was undef.
    > Etc.


    An example of the Etc.


    perl -Mstrict -MData::Alias -wle '
    #alias
    my $s = "foo,bar,baz";
    my @s;
    for my $i ( 0 .. 2 ) {
    alias $s[ $i ] = substr( $s, $i * 4, 3 );
    }
    eval { $s[ 1 ] = "xyz"; 1 } or warn "w: ", $@;
    print $s;
    print "@s";
    '
    foo,xyz,baz
    foo xyz baz


    Also try the above with the '#' removed from line 2.

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #5
  6. Klaus

    Guest

    Re: Data::Alias

    On Aug 19, 9:22 am, "Dr.Ruud" <> wrote:
    >
    > It is/was a great module. It should be resurrected.



    Data::Alias certainly is a great module. I've loved it ever since
    Ben Morrow introduced me to it. When used correctly, it makes code
    much more readable (and comprehensible to those who struggle with
    references).

    Programmers new to Perl often discover that @arrays and %hashes
    aren't passed in and out of functions in quite the same way that
    scalars are. As a result, they're more likely to declare many of
    their @arrays and %hashes as global variables (or to avoid
    declarations and "use strict" altogether) than to deal with passing in
    references and correctly dereferencing them with $ref->{...} and $ref-
    >[...] syntax (which is tricky to get right when not familiar with

    them).

    For this reason I think that Data::Alias should be made a core
    module of Perl. Perl programmers (and Perl programs) as a whole will
    be better off once they all have access to the Data::Alias module.

    But that's just my opinion. ;)

    -- Jean-Luc
     
    , Aug 19, 2010
    #6
  7. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    wrote:
    > On Aug 19, 9:22 am, "Dr.Ruud" <> wrote:
    >> It is/was a great module. It should be resurrected.

    >
    >
    > Data::Alias certainly is a great module. I've loved it ever since
    > Ben Morrow introduced me to it. When used correctly, it makes code
    > much more readable (and comprehensible to those who struggle with
    > references).
    >
    > Programmers new to Perl often discover that @arrays and %hashes
    > aren't passed in and out of functions in quite the same way that
    > scalars are. As a result, they're more likely to declare many of
    > their @arrays and %hashes as global variables (or to avoid
    > declarations and "use strict" altogether) than to deal with passing in
    > references and correctly dereferencing them with $ref->{...} and $ref-
    >> [...] syntax (which is tricky to get right when not familiar with

    > them).
    >
    > For this reason I think that Data::Alias should be made a core
    > module of Perl. Perl programmers (and Perl programs) as a whole will
    > be better off once they all have access to the Data::Alias module.
    >
    > But that's just my opinion. ;)


    I agree to the "core module" part, but not to the syntax parts.
    I would never recommend Data::Alias for such a reason. To me it
    is mainly a module that brings better performance.


    alias my %foo = %{ $table->{ foo } };

    allows one to write

    $foo{ key }

    in stead of

    $table->{ foo }{ key }

    and that performs better.


    perl -Mstrict -MData::Dumper -MData::Alias -MBenchmark=cmpthese -wle'
    my $href;
    alias my %foo = %{ $href->{ foo } };

    $foo{ test }= 0;
    #print "\n", Dumper( $href );

    cmpthese( -1, {
    plain => sub { $href->{ foo }{ test }= 1 },
    alias => sub { $foo{ test }= 2 },
    });

    #print "\n", Dumper( $href );
    '

    Rate plain alias
    plain 2194985/s -- -54%
    alias 4812084/s 119% --

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #7
  8. Klaus

    Uri Guttman Guest

    Re: Data::Alias

    >>>>> "R" == Ruud <> writes:

    R> I agree to the "core module" part, but not to the syntax parts.
    R> I would never recommend Data::Alias for such a reason. To me it
    R> is mainly a module that brings better performance.

    it is still just syntax sugar.


    R> $foo{ key }

    R> in stead of

    R> $table->{ foo }{ key }

    i never write deep hashes like that more than one time. i take refs to
    the deeper level and use that. so the speed savings can be done without
    this module. it may be nice and cute but it isn't any major win in speed
    or syntax. you can't use it to hide from refs all the time. and it makes
    the code maintainer learn all its tricks before he can work on the code.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Aug 19, 2010
    #8
  9. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    Uri Guttman wrote:
    >> <> writes:


    >> I agree to the "core module" part, but not to the syntax parts.
    >> I would never recommend Data::Alias for such a reason. To me it
    >> is mainly a module that brings better performance.

    >
    > it is still just syntax sugar.


    Or you are just wrong.


    >> $foo{ key }
    >>
    >> in stead of
    >>
    >> $table->{ foo }{ key }

    >
    > i never write deep hashes like that more than one time. i take refs to
    > the deeper level and use that. so the speed savings can be done without
    > this module.


    perl -Mstrict -MData::Alias -MBenchmark=cmpthese -wle'
    my $h;
    alias my %alias = %{ $h->{ foo } };
    $alias{ test }= 0;
    my $plain= $h->{ foo };

    cmpthese( -1, {
    plain => sub { $plain->{ test }= 1 },
    alias => sub { $alias{ test }= 2 },
    });
    '
    Rate plain alias
    plain 3276800/s -- -28%
    alias 4549606/s 39% --


    (just because dereferencing has runtime costs)


    > it may be nice and cute but it isn't any major win in speed
    > or syntax. you can't use it to hide from refs all the time. and it makes
    > the code maintainer learn all its tricks before he can work on the code.


    What a loss of cycles that you just never found out how much more it is.

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #9
  10. Klaus

    Guest

    On Thu, 19 Aug 2010 04:01:13 -0700 (PDT), Klaus <> wrote:

    >- Do you recommend upgrading from perl 5.10 (x64) to the newer perl
    >5.12 (x64) at the same time ?


    I would say absolutely not do this at the same time.
    It complicates the issue.
    Certify the existing production code to 2008 with
    the version 5.10 that is compatable with 2008
    (if there is such a thing. Which for Perl, I don't think
    there is that granularity at the OS level, only 32/64 bit,
    which I think is the 2003 server sdk headers/libs).


    -sln
     
    , Aug 19, 2010
    #10
  11. Klaus

    Uri Guttman Guest

    Re: Data::Alias

    >>>>> "R" == Ruud <> writes:

    R> perl -Mstrict -MData::Alias -MBenchmark=cmpthese -wle'
    R> my $h;
    R> alias my %alias = %{ $h->{ foo } };
    R> $alias{ test }= 0;
    R> my $plain= $h->{ foo };

    R> cmpthese( -1, {
    R> plain => sub { $plain->{ test }= 1 },
    R> alias => sub { $alias{ test }= 2 },
    R> });
    R> '
    R> Rate plain alias
    R> plain 3276800/s -- -28%
    R> alias 4549606/s 39% --


    how often would you need to do a single level hash lookup to save here?
    if i needed it so often i would copy to a scalar or make a ref to
    it. again, not often so it isn't a win unless you have very odd or bad
    old code.

    R> (just because dereferencing has runtime costs)

    and this is doing a dereference under the hood. hash lookups are a
    different matter. compare alias to $ref = \$plain->{test} and
    ${$ref}. those should be about the same.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Aug 19, 2010
    #11
  12. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    Uri Guttman wrote:

    > and this is doing a dereference under the hood. hash lookups are a
    > different matter. compare alias to $ref = \$plain->{test} and
    > ${$ref}. those should be about the same.


    You really still don't get it. But I never get tired promoting
    Data::Alias, so no problem here.

    Data::Alias does many things at compile time, by changing the op-tree.
    No "dereference under the hood"!


    Another nice (memory saving) functionality of Data::Alias:

    perl -Mstrict -MData::Alias -MDevel::Size=size,total_size
    -MBenchmark=cmpthese -wle'
    my ( %plain, %slice, %alias );
    my @keys= "aaaa" .. "zzzz";
    my $VALUE= "foo";

    print "keys: ", scalar @keys;

    cmpthese( -1, {
    slice => sub { @slice{ @keys }= ($VALUE) x @keys },
    plain => sub { $plain{ $_ }= $VALUE for @keys },
    alias => sub { alias $alias{ $_ }= $VALUE for @keys },
    });

    print "";
    for ( [ plain => \%plain ], [ slice => \%slice ], [ alias => \%alias
    ] ) {
    print sprintf qq{%s k=%s, v=%s}, $_->[0], size( $_->[1] ),
    total_size( $_->[1] ) - size( $_->[1] );
    }
    '
    keys: 456976
    Rate slice alias plain
    slice 3.33/s -- -13% -19%
    alias 3.81/s 14% -- -8%
    plain 4.13/s 24% 8% --

    plain k=13978588, v=12795328
    slice k=13978588, v=12795328
    alias k=13978588, v=28

    Try also with slice initialised to (), then make the $VALUE undef.
    You'll find that slice is twice as fast, but still uses (for no good
    reason) quite some memory for all the undef-SVs.

    This is a nice way to implement sets, where all you need is exists().
    Or any other situation where the values come in packs.

    Cheers!

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #12
  13. Klaus

    Uri Guttman Guest

    Re: Data::Alias

    >>>>> "R" == Ruud <> writes:

    R> Uri Guttman wrote:
    >> and this is doing a dereference under the hood. hash lookups are a
    >> different matter. compare alias to $ref = \$plain->{test} and
    >> ${$ref}. those should be about the same.


    R> You really still don't get it. But I never get tired promoting
    R> Data::Alias, so no problem here.

    R> Data::Alias does many things at compile time, by changing the op-tree.
    R> No "dereference under the hood"!

    ok, i didn't know about its guts. but the fact that it messes with
    perl's guts scares me too. as someone pointed out it broke under a newer
    perl. that is not the kind of module i want to depend upon.

    uri

    --
    Uri Guttman ------ -------- http://www.sysarch.com --
    ----- Perl Code Review , Architecture, Development, Training, Support ------
    --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
     
    Uri Guttman, Aug 19, 2010
    #13
  14. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    Uri Guttman wrote:
    > <> writes:
    >> Uri Guttman wrote:


    >>> and this is doing a dereference under the hood. hash lookups are a
    >>> different matter. compare alias to $ref = \$plain->{test} and
    >>> ${$ref}. those should be about the same.

    >>
    >> You really still don't get it. But I never get tired promoting
    >> Data::Alias, so no problem here.
    >>
    >> Data::Alias does many things at compile time, by changing the op-tree.
    >> No "dereference under the hood"!

    >
    > ok, i didn't know about its guts. but the fact that it messes with
    > perl's guts scares me too. as someone pointed out it broke under a newer
    > perl. that is not the kind of module i want to depend upon.


    Well, don't get too afraid of op-tree manipulations yet, because there
    is a whole new set of tools coming to do just that, though in a better,
    more controllable and sustainable way, and even in Perl (compare
    Devel::Declare).

    That is also more or less the way that Data::Alias should get fixed.
    It needed to be fixed after multiple Perl releases, and because it isn't
    in core, that is lagging.

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #14
  15. Klaus

    Dr.Ruud Guest

    Re: Data::Alias

    Dr.Ruud wrote:

    > Another nice (memory saving) functionality of Data::Alias:
    >
    > perl -Mstrict -MData::Alias -MDevel::Size=size,total_size
    > -MBenchmark=cmpthese -wle'
    > my ( %plain, %slice, %alias );
    > my @keys= "aaaa" .. "zzzz";
    > my $VALUE= "foo";
    >
    > print "keys: ", scalar @keys;
    >
    > cmpthese( -1, {
    > slice => sub { @slice{ @keys }= ($VALUE) x @keys },
    > plain => sub { $plain{ $_ }= $VALUE for @keys },
    > alias => sub { alias $alias{ $_ }= $VALUE for @keys },
    > });
    >
    > print "";
    > for ( [ plain => \%plain ], [ slice => \%slice ], [ alias => \%alias ]
    > ) {
    > print sprintf qq{%s k=%s, v=%s}, $_->[0], size( $_->[1] ),
    > total_size( $_->[1] ) - size( $_->[1] );
    > }
    > '
    > keys: 456976
    > Rate slice alias plain
    > slice 3.33/s -- -13% -19%
    > alias 3.81/s 14% -- -8%
    > plain 4.13/s 24% 8% --
    >
    > plain k=13978588, v=12795328
    > slice k=13978588, v=12795328
    > alias k=13978588, v=28
    >
    > Try also with slice initialised to (), then make the $VALUE undef.
    > You'll find that slice is twice as fast, but still uses (for no good
    > reason) quite some memory for all the undef-SVs.
    >
    > This is a nice way to implement sets, where all you need is exists().
    > Or any other situation where the values come in packs.
    >
    > Cheers!


    You can do similar things with arrays:

    perl -Mstrict -MData::Alias -MDevel::Size=size,total_size -wle'

    my ( $MAX, $undef, @plain, @sparse, @alias )= ( 1234567 );

    $plain[ $_ ]= $undef for 0 .. $MAX;
    $sparse[ $MAX ]= $undef;
    alias $alias[ $_ ]= $undef for 0 .. $MAX;

    my %existing;

    print "";
    for ( [ plain => \@plain ],
    [ spars => \@sparse ],
    [ alias => \@alias ],
    ) {
    my ( $k, $v ) = @$_;
    $existing{ $k }= scalar grep exists $v->[ $_ ], 0 .. $#$v;
    print sprintf qq{%s meta=%s B, data=%s B, k#=%s},
    $k,
    size( $v ),
    total_size( $v ) - size( $v ),
    $existing{ $k };
    }
    '

    plain meta=8388740 B, data=14814816 B, k#=1234568
    spars meta=4938420 B, data=12 B, k#=1
    alias meta=8388740 B, data=12 B, k#=1234568


    So use sparse arrays if not many slots will be occupied,
    and use Data::Alias if you have a lot of equal values in the array.

    But also look into the Vector modules, and into PDL,
    and find out what is fittest in your context.

    --
    Ruud
     
    Dr.Ruud, Aug 19, 2010
    #15
  16. Klaus

    l v Guest

    On 8/19/2010 6:01 AM, Klaus wrote:
    > Hello,
    >
    > I hope this post is not OT in c.l.p.m.
    >
    > I have got a couple of medium-sized (1000+ lines of code) of Perl
    > programs (64 bits) running on Windows Server 2003, the perl version
    > is:
    >
    > C:\>perl -v
    > This is perl, v5.10.1 built for MSWin32-x64-multi-thread
    > (with 2 registered patches, see perl -V for more detail)
    > Binary build 1007 [291969] provided by ActiveState http://www.ActiveState.com
    > Built Jan 27 2010 14:12:21
    >
    > I am using ADODB to connect to MSAccess databases, I read
    > ActiveDirectory entries and I use StorageCentral to setup Storage
    > quotas for 1000+ directories.
    >
    > Now I have to migrate Windows Server from 2003 to 2008.
    >
    > Before I embark on this adventure, I would ask for the wisdom of the
    > perl user community:
    >
    > - Does anybody have experience with migrating perl programs from
    > Windows Server 2003 to 2008 ?
    >
    > - Are there any pitfalls I need to be aware of ?
    >
    > - Do you recommend upgrading from perl 5.10 (x64) to the newer perl
    > 5.12 (x64) at the same time ?


    I would keep the Perl version the same during the server migration /
    upgrade so as not to complicate the migration.

    I'm sure I'll catch some flak over this. I the past on older Windows
    OSes, I would install Perl in the same drive and directory location on
    the 2008 box as it was installed on the 2003 box. Then copy the 2003
    Perl installation to the 2008 box. I never uncounted any problems with
    this procedure.

    --
    Len
     
    l v, Aug 20, 2010
    #16
  17. l v <> writes:

    > On 8/19/2010 6:01 AM, Klaus wrote:


    <snip>
    >> Now I have to migrate Windows Server from 2003 to 2008.
    >>
    >> Before I embark on this adventure, I would ask for the wisdom of the
    >> perl user community:
    >>
    >> - Does anybody have experience with migrating perl programs from
    >> Windows Server 2003 to 2008 ?
    >>
    >> - Are there any pitfalls I need to be aware of ?
    >>
    >> - Do you recommend upgrading from perl 5.10 (x64) to the newer perl
    >> 5.12 (x64) at the same time ?

    >
    > I would keep the Perl version the same during the server migration /
    > upgrade so as not to complicate the migration.
    >
    > I'm sure I'll catch some flak over this.


    Why?

    It's common sense in doing systems administration: never execute more
    than one change at a time. If something goes wrong, you don't have to
    first debug which change cased the problem, you can just roll back the
    last change.

    Mart

    --
    "We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.
     
    Mart van de Wege, Aug 20, 2010
    #17
  18. On Fri, 20 Aug 2010 16:55:33 +0200, Mart van de Wege wrote:

    > l v <> writes:
    >
    >> I'm sure I'll catch some flak over this.

    >
    > Why?
    >
    > It's common sense in doing systems administration: never execute more
    > than one change at a time. If something goes wrong, you don't have to
    > first debug which change cased the problem, you can just roll back the
    > last change.
    >


    Not quite, it's always a risk/benefit trade off. If rollback is easy and
    the risks are low, it may very well be beneficial to bother your users
    only once and do all changes at once.

    And as you tested all changes beforehand, the risks should be low.

    (I currently work in a bank where every environment has a complete DTAP
    street where this holds, and at the some other gig where you are lucky if
    some test environment can be freed, all IT is outsourced and changes
    normally go sour. Guess which one follows which change model...)

    M4
     
    Martijn Lievaart, Aug 20, 2010
    #18
  19. Martijn Lievaart <> writes:

    > On Fri, 20 Aug 2010 16:55:33 +0200, Mart van de Wege wrote:
    >
    >> l v <> writes:
    >>
    >>> I'm sure I'll catch some flak over this.

    >>
    >> Why?
    >>
    >> It's common sense in doing systems administration: never execute more
    >> than one change at a time. If something goes wrong, you don't have to
    >> first debug which change cased the problem, you can just roll back the
    >> last change.
    >>

    >
    > Not quite, it's always a risk/benefit trade off. If rollback is easy and
    > the risks are low, it may very well be beneficial to bother your users
    > only once and do all changes at once.
    >

    Well, nothing precludes you from rolling out your changes in a single
    change window of course.

    But you'd still be smart to execute each part in sequence and only after
    confirming functionality continue to the next change.

    So in OP's case, I'd do the OS upgrade, test if the application still
    works, Perl upgrade, test again. (or Perl first, depending on how easy a
    rollback is).

    > And as you tested all changes beforehand, the risks should be low.


    Heh. If only. Experience tells me that there is always a chance that
    something that worked in testing falls flat in production.

    Mart

    --
    "We will need a longer wall when the revolution comes."
    --- AJS, quoting an uncertain source.
     
    Mart van de Wege, Aug 21, 2010
    #19
  20. On Sat, 21 Aug 2010 10:31:15 +0200, Mart van de Wege wrote:

    > Heh. If only. Experience tells me that there is always a chance that
    > something that worked in testing falls flat in production.


    In some environments where I work, it is more than "a chance". :)

    M4
     
    Martijn Lievaart, Aug 21, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Krist
    Replies:
    6
    Views:
    805
    Arne Vajhøj
    May 7, 2010
  2. Chris

    migration issue with ASP on win 2003

    Chris, Apr 26, 2005, in forum: ASP General
    Replies:
    3
    Views:
    168
    Chris
    May 5, 2005
  3. Jim Moon
    Replies:
    4
    Views:
    183
    Jim Moon
    Apr 15, 2005
  4. Ted
    Replies:
    7
    Views:
    601
    Sisyphus
    Dec 16, 2006
  5. Boni Satani
    Replies:
    0
    Views:
    194
    Boni Satani
    Jan 9, 2014
Loading...

Share This Page