Search results for query: *

I still think that importing the whole file to a stage table is better but don't worry. It is just that you could copy the whole thing in and the processing you are talking about is then between the stage and stage2 for example table. All in SQL then so quicker...

You can do the equivalent. @X=0 While X < 100 Begin @X = @X + 1 etc. Cursors are more complicated but very handy

If all your files are of a certain naming convention or they are just ALL the text files in a directory for example there are many ways of getting SQL to loop until it has them all so don't bother with FSO for appending. You need a loop, a staging table and a working directory. Loop through the...

OK that is a little picky. < or > would you be happy with? If you really want to be good about data integrity then set the field to be BIT with a default of 0 and then test it as a 1 or 0. The advantage of a convert if you are going to use a number in a text field is that it deals with zero...

I know it is not helpful but that is why we do Windows logon authority. I never allow an 'out of the box' username to stick around for long. Too many security issues.

I would do a convert on it Select convert(decimal(9,2),Column) The only issue you have is then if it is blank. It doesn't like that. I did find a work around with convert(money, column). This will treat blanks, spaces or zero length fields as a zero. Then you can do maths functions like <>

Is your flat file always being added to? I am not sure what you are after but scheduling a job to import from flat files is fine. If the file is being added to you may need to copy/move it locally so it can be processed while more is added to the original. DTS is the obvious choice I think...

I always use cursors to deal with this. Define a select for the cursor and step through turning the rows into columns. The only proviso is that you need to know your maximum number of columns or you need to get into heavy duty stuff where you build the table in code too. The cursors will work...

Just a second thought as well. Don't forget that your IQD files are text as well. They can be edited quite happily as long as you are careful. If all else fails then redo your catalog. As long as the data arrives with the same column headings from the catalog folders you should not have too...

There are text files that you can import yourself into whatever DB you like. We tend to do that to answer specific questions (Did anyone use the new measure X?)and very generic ones (how many users hit the cube in a day)

If you are just moving your databases (different server or whatever) then you can just change your ODBC links to point to the new datasources. They do need to be identical to do this though, table structures and names for example, or it won't work.