May 29, 2012 at 2:43 pm
I need to move a DB from SQL server 2008 R2 on a Window7_64 machine to a WindowXP_32 (not sure that the machine would survive to an update to window7_32bit as the memory is limited and has a very old CPU). There is no network for now. It might be possible to have network between the two machine (maybe, not sure).
The DB is small (4Mb) so I can do it manualy. I thought to detach the DB from the 64 and copy it onto the 32 bits machine using USB or DVD, but I have no idea how to convert the 64 bits version into a 32 version.
I suppose the best way is to create scripts for the structure: is there a way to script all the tables at once?
I don't khow how to script the data itself (into the tables) unless creating a program to copy data into files, then from the files into DB.
Any idea that would help me?
May 29, 2012 at 2:46 pm
tilew-948340 (5/29/2012)
I need to move a DB from SQL server 2008 R2 on a Window7_64 machine to a WindowXP_32 (not sure that the machine would survive to an update to window7_32bit as the memory is limited and has a very old CPU). There is no network for now. It might be possible to have network between the two machine (maybe, not sure).The DB is small (4Mb) so I can do it manualy. I thought to detach the DB from the 64 and copy it onto the 32 bits machine using USB or DVD, but I have no idea how to convert the 64 bits version into a 32 version.
I suppose the best way is to create scripts for the structure: is there a way to script all the tables at once?
I don't khow how to script the data itself (into the tables) unless creating a program to copy data into files, then from the files into DB.
Any idea that would help me?
As long as you are going from 2008R2 (64 bit) to 2008R2 (32 bit) there is nothing you need to do to the database.
May 29, 2012 at 2:56 pm
tilew-948340 (5/29/2012)
I need to move a DB from SQL server 2008 R2 on a Window7_64 machine to a WindowXP_32 (not sure that the machine would survive to an update to window7_32bit as the memory is limited and has a very old CPU). There is no network for now. It might be possible to have network between the two machine (maybe, not sure).The DB is small (4Mb) so I can do it manualy. I thought to detach the DB from the 64 and copy it onto the 32 bits machine using USB or DVD, but I have no idea how to convert the 64 bits version into a 32 version.
I suppose the best way is to create scripts for the structure: is there a way to script all the tables at once?
I don't khow how to script the data itself (into the tables) unless creating a program to copy data into files, then from the files into DB.
Any idea that would help me?
Can't you just create a backup and restore that on the 32-bit machine?
If you must script it (which I don't you do) you can the objects AND data. To do this right click your database -> Tasks -> Generate Scripts. This will bring up a very robust script generating tool. There is an option in there to script data along with the objects.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
May 29, 2012 at 3:00 pm
There isn't a 64bit disk file and a 32 bit disk file. They are the same.
detach/attach or backup/restore as Lynn noted.
May 29, 2012 at 8:51 pm
When I tried to read the SLQserver 2008 R2 DB with the SQL server 2008 and it did not work, I would have bet that it was because a 32 bit operating system can't read a 64 bit file coming from a 64 bit operating system...
So, if I just update to 2008 R2 like it was planed, my problem would be solve!? :crazy:
Should have thought of that...:ermm: ...sorry!
Thanks
May 30, 2012 at 1:35 am
tilew-948340 (5/29/2012)
When I tried to read the SLQserver 2008 R2 DB with the SQL server 2008 and it did not work, I would have bet that it was because a 32 bit operating system can't read a 64 bit file coming from a 64 bit operating system...So, if I just update to 2008 R2 like it was planed, my problem would be solve!? :crazy:
Should have thought of that...:ermm: ...sorry!
Thanks
You cannot restore a higher version DB to a lower version DB which is what your doing in this case, it has nothing to do with it being 32bit or 64bit.
2008R2 --> 2008 Wont work
2008 --> 2008R2 Will work
2008R2 --> 2008R2 Will work
2008 --> 2008 Will work
May 30, 2012 at 2:15 am
tilew-948340 (5/29/2012)
I would have bet that it was because a 32 bit operating system can't read a 64 bit file coming from a 64 bit operating system...
32 bit vs 64 bit is just the CPU operation size and to do with the memory addressing. It does not affect file structure or anything on-disk. Files of any form can be copied from 32 bit to 64 bit and back without any problem (SQL database files, Word docs, spreadsheets, etc, etc)
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 30, 2012 at 8:32 pm
GilaMonster (5/30/2012)
tilew-948340 (5/29/2012)
I would have bet that it was because a 32 bit operating system can't read a 64 bit file coming from a 64 bit operating system...32 bit vs 64 bit is just the CPU operation size and to do with the memory addressing. It does not affect file structure or anything on-disk. Files of any form can be copied from 32 bit to 64 bit and back without any problem (SQL database files, Word docs, spreadsheets, etc, etc)
It's been a long time since I did support on machines, but on a linux machine in those time, you certainly could never read a 64 bit file on a 32 bit operating system. I guess that today there is a converter by default on Window7 and probably on linux also, but my logic came from my past experience. It just prove that years in computing is a very very long time!
May 31, 2012 at 2:04 am
tilew-948340 (5/30/2012)
I guess that today there is a converter by default on Window7 ...
No converters. Most data files are identical between 32 bit and 64 bit (an app dev would have to explicitly code in a difference for there to be a difference, or write raw memory addresses to disk). Binaries, sure (and Windows can run 32 bit processes on a 64-bit OS), but not data files.
I've never once had a problem moving files (data, not binary) from a 32 bit machine to 64 or back, and I've been running 64 bit at home for some years now.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 31, 2012 at 4:17 am
GilaMonster (5/31/2012)
tilew-948340 (5/30/2012)
I guess that today there is a converter by default on Window7 ...No converters. Most data files are identical between 32 bit and 64 bit (an app dev would have to explicitly code in a difference for there to be a difference, or write raw memory addresses to disk). Binaries, sure (and Windows can run 32 bit processes on a 64-bit OS), but not data files.
I've never once had a problem moving files (data, not binary) from a 32 bit machine to 64 or back, and I've been running 64 bit at home for some years now.
Did you ever tried on Unix machine? I don't think so because I did have problem.
Moving from 32 to 64 is easy because the OS 64 is built to do it. It had to because of the migration from 32 to 64.
Moving from 64 to 32, it might depends on the type of the OS. Sure that it is well known that Unix and Mac did all the work and window just had to adjust their OS... but that would open a discussion that is as old as the history of computers and I don't want to go over there 🙂
At least we agree on the binary!
May 31, 2012 at 4:36 am
Haven't used unix since university. Maybe depends on the file type, but the vast majority of data files that you'll encounter on windows (SQL data and log file, word docs, text files, spreadsheets, powerpoint, images, game save files, etc) do not depend on the processor architecture. They're fixed data formats
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
May 31, 2012 at 11:20 am
I don't think this is true. I could easily copy binary files or text files on Unix machines from 64bit Solaris to 32 bit Solaris.
I can't execute a 64 bit file on a 32 bit machine, but there's no issue copying the file.
If you had file system converters, it was because the file system changed, not because of 32 v 64 bit architectures.
May 31, 2012 at 5:39 pm
I don't want to argue too much on that because I am no expert. I found this site that explains why a 32 bit OS would not run a 64 bit application http://www.techsupportalert.com/content/32-bit-and-64-bit-explained.htm (it is not about the arguing, because we argue on reading the file, but it was interesting anyway)
When I opened this discussion, I thought that the reason that SQL server 32 bit could not attach the DB saved on a 64 bits OS was not because of the SQL version (like MSword 2003 can't read MSword 2010 files), but because the file was saved in a 64 bits format and the 32 bit OS reads only half of every information, then passing it to the 32 bit application. You are telling me that I was wrong thinking like that...
I am still waiting for the upgrade from 2008 to R2, but when I'll get it and if it still does not work, I'll come back to you :satisfied: ... and if it works, I am still coming back to you to tell you that I am happy that it finaly works 😀
Thanks!
June 1, 2012 at 12:34 am
tilew-948340 (5/31/2012)
You are telling me that I was wrong thinking like that...
Yup. The data file and log file structures are dependant on the SQL version, not the processor architecture. I've moved databases from x86 to x86 and x86 to IA 64 and IA 64 to x64 a number of times.
The 32 bit vs 64 bit is about the size of the memory addresses and operations used by the processor, not the reading of data from the disk. A developer would have to explicitly code in a difference in file structures or write memory addresses directly to disk for there to be any difference.
I am still waiting for the upgrade from 2008 to R2, but when I'll get it and if it still does not work, I'll come back to you :satisfied:
It will work
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
June 1, 2012 at 11:24 am
tilew-948340 (5/31/2012)
I don't want to argue too much on that because I am no expert. I found this site that explains why a 32 bit OS would not run a 64 bit application http://www.techsupportalert.com/content/32-bit-and-64-bit-explained.htm (it is not about the arguing, because we argue on reading the file, but it was interesting anyway)
You are confusing the application execution with the file structure. The file structure on disk is the same. It's stored the same way.
The executable instructions inside the file are different for 64 bit programs, and if compiled for 64 bit, they will not execute on a 32 bit machine. The file can be read just fine.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply