DTS v ADO
-
I am fairly new to DTS packages. I'm more used to creating connection objects in VB (ADO) and then doing what I have to do. I've recently been toying with using disconnected recordsets to increase the efficiency of processing things in SQL server as I understand it will not use server resources (as I work in an environment where a lot of people may need to use the server) rather than using DTS packages. Many of my colleagues seem to have been taken in by the nice way that the process is displayed in DTS packages, but I am more concerned with making my processes more efficient. Can anyone give me any advice on which path to take and give any pros and cons of both methods. Also I've seen that in ActiveX tasks in DTS packages you can connect to recordsets and databases. Is it possible to go down the same route of disconnecting the recordset in an ActiveX task or does this always have to run on the server? Any advice would be useful as I'm new to the whole package.
-
Regardless of how its developed, or where it's stored, the DTS package will always run where it was executed from.
EG: If you use SQL Enterprise Manager on your workstation to manually execute a package stored on the server, the package will execute on your workstation, not the server. It will also use your security credentials while executing.
Hope this helps
Phill Carter
--------------------
Colt 45 - the original point and click interface
--------------------
Colt 45 - the original point and click interface
-
Not sure I understand what you are after. Are you talking about record display to the end user within an application? If so then DTS isn't a good choice, it is primarily for moving data to and from a SQL server but can be used to relay info between other systems. This doesn't help with display although you could use to send them a data export or allow data import but that requires the customer be controlled or you will end up with garbage.
I would stick with ADO and a controlled environment GUI such as VB. Disconnected recordsets are an awesome way to handle data (have read enough not done anything) but keep in mind if they will be doing updates what happens if two folks are working on the same record.
Beyond that might be better if we knew what you are trying to accomplish.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply