July 10, 2002 at 12:25 pm
I don't include SQLDMO v2000 in my installations and rely on client install. But I want to implement some SQLDMO 2000 specific features.
How can I tell the version of SQLDMO installed on client machine? is there a version property of SQLDMO to interrogate?
If so I will check it and implement 2000 specific features for that session only if the installation of SQLDMO supports it.
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
July 10, 2002 at 3:33 pm
Possibly you can do it like this, I dont have a machine handy with the SQL7 dmo dll's on it:
Set oapp = New SQLDMO.Application
Debug.Print oapp.VersionMajor & "." & oapp.VersionMinor
If that doesnt work I'd say there are two alternatives. One is to try to use object2 functionality at the very beginning and trap the error so you know to degrade. The other would be to determine the version of the dll (API call I think) directly.
Andy
July 10, 2002 at 7:13 pm
great, thanks
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
July 11, 2002 at 10:52 pm
This code should work better as you don't need the reference to the object loaded for it to work
dim oapp as object
Set oapp = createobject("SQLDMO.Application")
Debug.Print oapp.VersionMajor & "." & oapp.VersionMinor
🙂
July 11, 2002 at 11:23 pm
quote:
This code should work better as you don't need the reference to the object loaded for it to workdim oapp as object
Set oapp = createobject("SQLDMO.Application")
Debug.Print oapp.VersionMajor & "." & oapp.VersionMinor
🙂
thx - this helps too
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
July 12, 2002 at 4:55 am
Sorry, how is that better? By declaring as object you're late binding AND you lose intellisense??
Andy
July 12, 2002 at 8:24 am
Hi,
this approach is better because you don't have a static reference to SQLDmo. So there is no problem with the interfaces. It's true that you lose intellisense but just one moment before to compile declare all the sql-dmo objects as "object" and remove the reference to sql-dmo.
bye
Antonio
July 12, 2002 at 9:48 am
quote:
Hi,this approach is better because you don't have a static reference to SQLDmo. So there is no problem with the interfaces. It's true that you lose intellisense but just one moment before to compile declare all the sql-dmo objects as "object" and remove the reference to sql-dmo.
bye
Antonio
to solve this specific problem I have done this
' Load User Defined Functions
If g_objSQLServer.VersionMajor > 7 Then
Call LoadUDFs
End If
So if the version is SQL2000 it will then Load the UDFs into my own object model. If not then the UDF function will never be called.
You can see in the UDF method I make the reference to Database2. I can get away with this even if it is a SQL7 DMO dll because the method won't ever get called and won't trip a run time error.
So in this specific case where I only need a bit of SQL2000 specific functionality I can implement in this way.
In this way i avoid late binding, keep intellisense and all *should* work fine
Public Function LoadUDFs()
Dim sqlUDF As UserDefinedFunction
Dim sqlDB As SQLDMO.Database2
Set sqlDB = g_objSQLServer.Databases(g_objCn.DefaultDatabase)
For Each sqlUDF In sqlDB.UserDefinedFunctions
... do my thing
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply