locked
COM objects under 64-bit? RRS feed

  • Question

  • Hi everyone,

     

    Primary platform is Framework 2.0 under 32-bit

    Production platform will be Framework 2.0 under 64-bit.

     

    I'm concerned about what object should I use in order to launch DTS 2000/7.0 from our .Net service.

     

    Currently it tested fine from a 32-bit environment (sql server 2005 as backend).

     

    Reference: "Microsoft DTSPackage Object Library"

    Physical file:  dtspkg.dll

     

    My wonder,  is there any limitation when it's gonna to work on 64-bit?

     

    Generally speaking, any limitation/issue/drawback for COM objects under 64 bit??

    In my project properties appears Any CPU, x86, x64. I've got now Any CPU.

     

    Thanks for your advices,

     

     

    Thursday, January 25, 2007 11:21 AM

Answers

  • Do you mean Microsoft.SqlServer.Dts.Runtime namespace from SQL Server 2005? If yes, it can't run DTS 2000 packages, it can only run SSIS packages.

    The DTS 2000 only exists in 32-bit version, you can use it on 64-bit OS from 32-bit processes run in WOW64.
    Thursday, January 25, 2007 5:50 PM

All replies

  • Well, anyway, in any case. I assume that it'd provoke lots of pitfalls, drawbacks and so on.

    So then, could I use assemblies in order to launch DTS 2000???

    (Microsoft.SqlServer.Dts.Runtime.Application)

     

    Thanks again,

    Thursday, January 25, 2007 1:23 PM
  • Do you mean Microsoft.SqlServer.Dts.Runtime namespace from SQL Server 2005? If yes, it can't run DTS 2000 packages, it can only run SSIS packages.

    The DTS 2000 only exists in 32-bit version, you can use it on 64-bit OS from 32-bit processes run in WOW64.
    Thursday, January 25, 2007 5:50 PM
  • Hi Michael,

    Thanks a lot for your information.

    So that, could I deduce that such COM component will work fine on our Window Server 2003 Enterprise x64 Edition?

    Thanks again.

     

    Friday, January 26, 2007 8:31 AM
  • hi,

    is it so?

    Tuesday, January 30, 2007 10:39 AM
  • They will work on x64, but your application has to be 32-bit.

    So instead of Any CPU, compile it for x86 - it will then run in WOW64 and be able to access DTS COM objects (provided they are installed of course).
    Tuesday, January 30, 2007 10:51 AM
  • No, my project got a "ANYCPU". Which is the problem?

    Upload dtspkg.dll to the cluster. Or anything else?

    Tuesday, January 30, 2007 12:33 PM
  • If you compile for AnyCPU, the executable will run as 64-bit executable on x64 machine. You can only access 32-bit DLLs from 32-bit processes, so you would not have access to DTS objects if executable is compiled for AnyCPU. Your executable has to be compiled for x86 - then it will run in WOW64 on x64 machine (i.e. as 32-bit process, with access to 32-bit COM objects).

    I think it is more than one DLL, see redistributable docs in SQL 2000 docs for list of files that are might and should be copied, and proper installation instructions.
    Tuesday, January 30, 2007 6:27 PM
  • Thanks for that. I'll keep on mind.

    So that, leaving as 'Any CPU' it'd caused a pitfall..

    But gosh, I understand that my service will run as * in my Task Manager, 32 bit... It would not take advantatge of 64 bit at all...

    What a pity!! What could I do in order to fix that?

    AFAIK is just a dtspkg.dll, at least when I run my project from VS. VS take dtspkg.dll and it's created (suppose) a RCW called

    as "Interop.DTS.dll"

    Thanks again.

     

     

     

    Wednesday, January 31, 2007 12:00 PM
  •  enric vives wrote:

    But gosh, I understand that my service will run as * in my Task Manager, 32 bit... It would not take advantatge of 64 bit at all...

    What a pity!! What could I do in order to fix that?

    Move to SSIS of course!

    Thursday, February 1, 2007 8:04 AM
  • Ok, Michael, I'm totally agree with you, but listen to me:

    We've got around 500 dts "live" up and just ten SSIS running on-production in order to cover our business as usual. As time goes by dts will be transformed into .DTSX, of course!

    Currently have two services: one which throws exclusively dts 2000 and the new one which is that we're discussing at (both ssis and dts 2000)

    But, thanks indeed.

     

    Thursday, February 1, 2007 12:34 PM
  • DTS comming from SQL Server 2000, never mind 7.0, has never been supported on 64-bit. The initial engine support for 64-bit (Liberty?) only came along after the SQL Server 2000 had been relased, and clearly  decsion was made that only certain parts of the product would be ported. Forward compatability on hardware is rather a challenge I'd imagine, and going back to add new hardware support for old components like DTS would clearly have impacted the delivery of SQL 2005. MS have been clear about this strategy, so that seems fair to me, you cannot expect old products to be constantly updated to keep pace with new hardware or operating systems. I like my Windows 2003 64-bit over NT4 thanks.

    Also think about what adding 64-bit support means to something like a data engine, you need to do some fairly major work around memory managent to allow it to scale over all that nice memory 64-bit gives us. They did that work, and found there was no realistic way forward to make the orginal code base scale, so they wrote the SSIS pipeline. You will often hear variations on that point when speaking to team members at conferences and the like.

    Every few genartions in software refresh cycles you get a step change like this. The best thing that has happend is that DTS is still there and supported, so DTS just keeps on working. If your DTS solutions no longer scale, then it seems fair to accept that some re-work will be required, although I would agree that this step change is quite significant, but then so are the benefits and that seems like the trade off.

    Thursday, February 1, 2007 12:57 PM
  • hi Darren,

    No, no I'm not complaining about Microsoft's philosophy or regarding ssis at all. I'm complaining about tight dates and about the fact that I'll have to run my service as 32 bit only for keep in mind old ETL.

    SSIS is a very good tool!

    Thursday, February 1, 2007 5:49 PM