Frustration.. slow performace when editing a DTS

I have tried many things and even the worst case thing which I was trying to avoid i.e. uninstalled MSDE SP3 and Analysis Services and service packs but the problem is still not solved...

Whenever I open a DTS in design view and double click on the link (the line connecting the two) between the source and destination servers the PC goes to sleep and comes back after a long time and then the same problem occurs when I press on the transformation tab...

I know this may sound weird but that really is the case :eek:

Please help :oSounds like the DTS designer can not connect to one of the machines that the Data Transform Task is moving data to and/or from. Check the connection parameters, and make sure you can connect to all of the machines.|||Thanks for the reply.

The source is a MS-SQL server on the LAN while the destination is MSDE SP3 on my box. I have been doing similar data importing related tasks (with the same settings, source, and destination) in the past but never experienced this problem. I can connect to both machines so that part is also covered.

Connection parameters is new for me so can you please guide how to go about checking the connection parameters i.e. from where are these defined and what should be the settings??|||While still trying to solve the problem, I brought up task manager and I have concluded that everytime the problem happens the MMC.EXE process is choking the CPU...

Does this provide any clues?|||Connection parameters is new for me so can you please guide how to go about checking the connection parameters i.e. from where are these defined and what should be the settings??

Just double-click on the connections and check the login, machine name, and database. If all are good, then it is something else.

Frustration with UniqueIdentifiers (GUIDs)

We're trying to set a new standard at my office, of using GUIDs as database ID fields - all new tables in all databases will have a GUID as the ID field, using the UniqueIdentifier data type.

The problem that we are running into, is that different applications interpret the UniqueIdentifier data type differently - ADO 2.x interprets it with the opening and closing { } braces. ADO.NET does not include the { and } in the GUID structure, SQL Server Query Analyzer does not include the { } braces, and SQL Server Enterprise Manage does include the { }

so we end up with results like this:

ADO 2.x: {012345678-abcd-ef01-2345-6789abcd}
ADO.NET: 012345678-abcd-ef01-2345-6789abcd
Query Analyzer: 012345678-abcd-ef01-2345-6789abcd
Enterprise Manager: {012345678-abcd-ef01-2345-6789abcd}

The problem with this is in two parts:
1) VB6 does not have a GUID structure or data type, so we are treating GUIDs as strings... but VB6 doesn't recognize "{012345678-abcd-ef01-2345-6789abcd}" and "012345678-abcd-ef01-2345-6789abcd" as the same string
2) when sending a URL link through an email, the { } braces break the link - in all email applications that we have tested. This include Groupwise 6, Groupwise 6.5, IPSwitch Web IMail, Outlook 2000, and Outlook Express (IE 6).

We're becoming very frustrated with the problems at hand, and need to know how others have worked around these problems. Please respond with any kind of advice or any real life situations where you have encountered this and found a solution, etc.

Thanks.The workaround is simple: program around it.

Standardize on the "new form" without curly braces and never show the m in any other way.

In "old vb" this means writing two little transform methods. Hardly a hugh task.|||so you're basically saying that every application we ever write with GUIDs has to have special processing code inside of it to handle guids?

that doesn't seem to be very smart, if you ask me.|||Well every application you ever write will not connect to several different types of data sources, will it?

And the 2 odd lines of code in every application... is too much? Really? Then I question the need for GUIDs in your application. Why did you feel the need to use them?