Recent content by markVII

Usually this error is associated with MS Access, points to syntax error Seems like a security problem; make sure that the scheduled DTS runs in the same privilege context as your manual execution (the one you connect with)

Link the servers. Make sure the DTC (Distributed Transactions Coordinator) is up and running. Know ramifications (performance, resources etc).

Extended properties cannot be specified in the CREATE TABLE statement . They must be added with sp_addextendedproperty prosedure. and later retrieved with FN_LISTEXTENDEDPROPERTY function. All "standard" properties specified at design time could be retrieved with SELECT COLUMNPROPERTY(...

The recommended way to find metadata information is INFORMATION_SCHEMA views (based on underlying system tables like syscolumns) In your case: SELECT * FROM INFORMATION_SCHEMA.COLUMNS while it is possible to query system tables directly, it is not a good idea

Just remember to do this within context of transaction, with proper safeguards. Some thoughts: And if you have to transform the data before committing an update, and the transformation is a notch above trivial? What if each row in the returned select must be treated differently? The CASE...

A procedure or function would be more elegant solution. use this: SELECT (value1-value2) as diff FROM dbo.TMPTABLECOMPARE WHERE ABS(value1 - value2) < 5

I believe sysindexes would be the place. check INFORMATION_SCHEMA views, too

You can re-write it as a stored procedure with OUT prameter. --------------------------------------- create function format_data() RETURN VARCHAR(100) as BEGIN declare @return_string VARCHAR(100) select @return_string = EmployeeName + ' :' + DATEPART((PunchOut - PunchIn),HOUR) + ':' + GetDate()...

Use subquery. Something like this: select * from customers where date not in (select date from details)

No need for subqueries: select ld.device_name,dbdr.contact_priority,lc.contact_name from lst_device ld ,db_device_role dbdr ,lst_contact lc where LD.device_id = DBDR.device_id AND LC.contact_id = DBdr.contact_id IN

Where is your JOIN condition? Without it you are bound to get a cartesian product (cross-join). something like this: where cal.field = hist.field and hist.field=c1.field or, if you prefer SQL92/99 syntax: from cal JOIN hist ON field1=field2 JOIN c1 ONfield=field And if after that nothing...

Set-based operations are always the way to go, and should be used whenever possible. The soul of SQL are set operations. However, the procedural extensions (of which cursor is an impostant part) were not introduced just for fun of it. There are situations when only procedural approach will work.

Use WAITFOR DELAY|TIME between the tasks. It should not really matter as DDL is committed right away, but your server might be busy, or something. Also, if you are going to run it during installation time, use OSQL interface (not isql, which is an old DB-LIB interface). And, of course, test it...

Where do you run the script from? Works fine from my Query Analyzer. Nevertheless, I would separate the tasks anyhow, just to be on the safe side.

Use the forward only cursor, as I recommended in the previous thread.