Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2002-06-28 : 10:04:53
|
| Frikkie writes "This may seem not so complicated to you as it seems to me. I have yet to find the answer somewhere on this site.I developed my application on Windows ME with Visual Studio 6.0, together with Microsoft SQL Server 7.0 Desktop version, and ADO 2.5. Works wonderful.Now, I moved my application to a Windows XP Professional workstation computer. It works, but with one "minor" (to you) problem. The rowset (recordset) does not allow updating (deleting, adding, updating etc). But it did support it when it ran on Windows ME (the development PC). The provider is SQLOLEDB (c:\program files\common files\system\oledb\sqloledb.dll). When I looked at the differences between the 2 OS's files, XP's version is 2000.81.7713.0 - NT Intel x86, while ME's version is 7.1.8.19.I had the funny feeling that I was going to run into some problems with OS differences, but I didn't think it would be a problem like this one. Data Access Components (DAC) ought to work when I move an application developed on an older version of windows, to a newer version of windows. Did Microsoft suddenly decide to remove some "old" features from DAC? (like updating) because Windows XP is so good? I know I may sound like a complete idiot when it comes to these things, but Data Access Components should be backwards compatible, don't you think?Perhaps Microsoft SQL Server 7.0 does not work together with Windoes XP as suspected? I don't know. Could you please give me some advice on this situation.Thank you so much." |
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2002-06-28 : 10:51:54
|
| I tend to believe the OS is a tangential issue; the differing versions of the MDAC appears to be the real culprit.I agree with you generally that moving up-version in a code library should not break functionality. My best guess is that your ADO code was using an unsupported feature of the 2.5 MDAC and it was phased out in 2.7 (I believe that's the version you're running).Have you tried uninstalling the MDAC you have and re-installing 2.5?Jonathan Boott, MCDBA |
 |
|
|
AjarnMark
SQL Slashing Gunting Master
3246 Posts |
Posted - 2002-06-28 : 20:02:01
|
| The last time I talked with our support guys, uninstalling or rolling back a version of MDAC was a real pain in the butt! Before you go there, let me ask you this... does your table that you are trying to update have a Primary Key defined on it? I've heard of other challenges with doing updates on a table with no Primary Key (those were between Access and SQL Server, but maybe you're experiencing a similar problem).When you "moved [your] application" how did you go about doing that? |
|
|
|
Doug G
Constraint Violating Yak Guru
331 Posts |
Posted - 2002-06-29 : 18:51:32
|
| Even if you could, you don't want to install MDAC 2.5 on XP, which shipped with 2.6 or 2.7.If you copied tables via DTS, or used Access as an intermediary when transferring you probably lost all the pk's and indices.======Doug G====== |
|
|
|
|
|
|
|
|
OS Provider Differences