Gene Moody
asked on
MSOLEDB Provider for SQL Server: Cannot find data type <whatever>
Recently had to perform an emergency transfer of a SQL Server Database from one server to another - managed to create a virtual drive for the Database files to "live" on, and mounted them to the new server. Made the server "aware" of the new database, and everything seemed to be rolling fine.
Now, for some reason, it cannot find/access User-Defined Data Types, and there they are, plain as day, under the Database->Programmability- >Types->Us er-defined Data Types. Is there some sort of process I'v left out to tell the SQL Server that it needs these data types?
Oh yeah - I almost forgot: we're getting this error from an Access Application that directly "talks" to SQL Server. (Don't laugh too loud - it's supposed to be our Accounting Software.) If this makes any difference, which I don't believe that it does.
I'm not sure where to go from here... ?
Now, for some reason, it cannot find/access User-Defined Data Types, and there they are, plain as day, under the Database->Programmability-
Oh yeah - I almost forgot: we're getting this error from an Access Application that directly "talks" to SQL Server. (Don't laugh too loud - it's supposed to be our Accounting Software.) If this makes any difference, which I don't believe that it does.
I'm not sure where to go from here... ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Now patched to version 9.0.3042 - SP2 fully in effect.
No joy, error persists. Same place: encounters user data type (that exists in the database definition), errors out. Is there some "association" algorithm that should be run, or something? Or is SQL Server just that full of "automagical" capacity?
Frustrated, very frustrated... (...not your fault, mind you, but just noting the mindset to avoid possible misunderstandings...)
No joy, error persists. Same place: encounters user data type (that exists in the database definition), errors out. Is there some "association" algorithm that should be run, or something? Or is SQL Server just that full of "automagical" capacity?
Frustrated, very frustrated... (...not your fault, mind you, but just noting the mindset to avoid possible misunderstandings...)
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Okay - this is extremely embarassing! It turns out that the problem wasn't in SQL Server at all - no, it was in how the application was handling things.
It turns out that there was a third Database - SYS - that contained (among other things) references to where those UDT's were kept: more lousy development on their part, as this is something SQL Server will do auto-magically, if you let it. But I guess it's to be expected: they used MSAccess 2K3 as their application "front end", and that's caused no end of troubles when setting it up on machines that have Office 2K7 or the like. SYS needed backing up, deleting, re-building, and then restoring (overwrite?) from the backup to make it all work right. And no, it's nothing that we would have thought of in a thousand years...
So, while were doing everything that we knew to do, nobody thought to see if the application platform was short-circuiting the existing system.
I'm truly sorry I bothered everybody, since it was third-party error in the first place. How do we handle this sort of situation?
It turns out that there was a third Database - SYS - that contained (among other things) references to where those UDT's were kept: more lousy development on their part, as this is something SQL Server will do auto-magically, if you let it. But I guess it's to be expected: they used MSAccess 2K3 as their application "front end", and that's caused no end of troubles when setting it up on machines that have Office 2K7 or the like. SYS needed backing up, deleting, re-building, and then restoring (overwrite?) from the backup to make it all work right. And no, it's nothing that we would have thought of in a thousand years...
So, while were doing everything that we knew to do, nobody thought to see if the application platform was short-circuiting the existing system.
I'm truly sorry I bothered everybody, since it was third-party error in the first place. How do we handle this sort of situation?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The problem actually resided in the third-party application, not SQL Server itself. However, without the expert's guidance and creativity, the problem might not have been noticed. Therefore...
ASKER
<code>
WITH Version(ver)
AS
(
SELECT SUBSTRING
(
@@VERSION,
CHARINDEX(' - ', @@VERSION)+3,
32
)
)
SELECT Build = LEFT(ver, CHARINDEX(' ', ver))
FROM Version
</code>
Results: 1 row(s) affected
9.00.1399.06
...meaning I'm running the RTM, no apparent patches or service packs installed.
So, now it's off to find the latest service pack for SQL Server 2005 Standard, right? Right.
Microsoft Data Access Components (MDAC) 2000.086.3959.00 (srv03_sp2_rtm.070216-1710