DSXchange

No problem.

If you do a LIST.INDEX MyHashedFile ALL then it will tell you whether or not you need a BUILD.INDEX. You need exclusive access to build the index.

1) No. The performance seems to be consistent across the number of rows. The issue is you need to load the hashed file which takes longer based on the number of rows. 2) If your whole hashed file will not fit in 128mb then it will put it in cache. Also when you are writing to a hashed file in cache ...

The ODBC drivers can be set to read only. Your user may not have write permission to this table.

Buy Parameter Navigator and save yourself some heartache.

If you really have to do this then parameterize the table name and the value in the column and associate them in each run. I would put them in a table. ColumnValue TableName A TableA B TableB Then loop thru these and feed them into the job one at a time. select * from source.table where ColumnWhatev...

You made my day. Thanks dude.

Use convert(). Much easier to control what gets converted to what.

Life is easier when you make it a varchar then it does not change it.

Ken Bland has given some of more detailed answers on this. Do a search.

This routine needs to be consistent. That was my problem it was not consistent across DEV, TEST and PROD. It needs to generate the same number across machines for the same string. It relies on overflow which was not consistent. Beware.

It should of found the old project and upgraded it. Does it show up? If not then you might try to create a project in the same location.

There you go. "Way more faster." You don't get a more better recommendation than that.

It has one argument the string to calculate the CRC32 on.

Shouldn't tease a Texan about his manhood or his nephew. Not nice.