DSXchange

All options are open. I think this can be resolved without custom operator, however. The solution has to be left with, and maintained by, the client, where there are no C++ skills. Outline of design is a sequence to traverse the list of table names, and a (perhaps multi-instance) subsequence to trav...

Well, the time part is easy, as that's a constant.

As to the date part, simply subtract one more than the day number from the date, using DateFromDaysSince() function.

It is not safe unless you perform corresponding operations on all the related tables. The XMETA database must be kept in a consistent state. And, no, I don't know which tables these are. This information is not only not documented, it is not enforced through metadata (it is enforced through the appl...

I'm rather hoping that someone else has already solved this problem. Please note that this was presented as a technical challenge, so my normal "resist stupid requirements" advice can not apply. If necessary I could probably argue for two or three jobs for (3)(c) solution, but definitely n...

I have been given a task with which I'd appreciate some guidance. The job is to move a large number of tables from Oracle and Microsoft SQL Server into another database (to be determined). The requirements are to perform each of the following with a generic job in each case (that is, one job that ca...

Which stage actually threw the error? You need to disable operator combination to find out. Then we'll be further along the road to diagnosis.

You really only benefit from a larger buffer if you have very wide rows. For "normal" processing, the default usually works well.

Look in SQL Server to see whether the connection is still present/open.

Change nothing.

This was a one-off event, and you no longer have any evidence that might suggest a cause. For example it may have been something totally unrelated to anything you can tune on the server - a database lock, for example.

There is a separate DS_JOBS table in each project. You can get the name of the project through the @ACCOUNT system variable. In an SQL statement you would need to encase this system variable in an EVAL expression.

In particular look for any column that has an empty precision value but has a data type that requires precision.

This message comes from the Connector Access Service. None of those messages yet appear in the Information Server messages manual.

The answer is still no.

What you're doing is correct. It's not a short cut. The "count rows" aggregation method is one of three available.

Field names don't contain ".". Therefore I deduce that the field name is "act", it is in a table called "lnk", and (from the error message) that one or both of these do not exist in DB2.