February 11, 2022 at 3:08 am
p.s. And, the files will be smaller because INTs will actually only take 4 bytes and dates will only take a maximum of 8 and could be as little as 3 bytes each. That also means smaller files to transmit and smaller is also faster and BCP is so fast that it'll yawn at just 100,000 rows even if it had to do 20 such files in rapid succession.
And, yeah... you can call it with PowerShell but... really?
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2022 at 3:11 am
Another way of doing it is to create a small special purpose, single table database that you write the "export' data to as a real table. Then do a compressed backup, send it to the other side or give them access to it, and let them restore the small database in seconds. Then they can do an INSERT INTO from that small database and, when done, simply drop the database.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2022 at 3:18 am
my reply must have go t lost...
The Data will increase and don't have to tie up any Network Traffic, so the route of csv would be I could zip the 3 files and move them across Network, and apply at Destination in off hours.. Using P/S(script) would be easier maintain since it would be outside SQL Mgmt
and visible by possible log file to show process.
Thanks again...
If you use a compressed backup of a single table database, you wouldn't have to worry about zipping anything and you wouldn't have to worry about doing it in "off hours". The same holds true with BCP because of it's incredible speed especially in the native format and especially compared to CSV.
It's your code, your machines, and your network but, using CSV is just the wrong way to do this, IMHO.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2022 at 2:02 pm
I choose the single table solution.
Many thanks for replies and suggestions.
Viewing 5 posts - 61 through 64 (of 64 total)
You must be logged in to reply to this topic. Login to reply