Benutzerdefinierte Funktionen unter SQL 2000
Michael Ronge
auf einem SQL-Server kann man neben Stored Procedures auch
benutzerdefinierte Funktionen erstellen, die gegenüber SPs einige
zusätzliche Vorteile besitzen.
Solange ich mit der VS.NET-IDE (Version 1.1) auf einen SQL-Server 7
zugreife, sehe ich die Funktionen im Explorer und kann sie mit den
Assistenten auswählen.
Auf einem SQL-Server 2000 werden die Funktionen nirgendwo angezeigt und
lassen sich nirgendwo auswählen. Hat jemand dafür eine Lösung!
Danke im voraus
Michael
Peter Koen
@TK2MSFTNGP10.phx.gbl:
Also ich weiß ja nicht was du gemacht hast genau, aber wenn ich bei mir im
Server Explorer unter Data Connections eine Datenbank eintrage die auf
einem SQL Server 2000 läuft so bekomme ich "Database Diagrams", "Tables",
"Views", "Stored Procedures" und "Functions".
Wenn ich den Vorgang mit einem User wiederhole der nur DataReader ist
fehlen mir bspw. die Diagramme. Also eventuell solltest du einmal deine
Berechtigungen auf der Datenbank nachkontrollieren.
Gruß
Peter
--
------ooo---OOO---ooo------
Peter Koen - www.kema.at
MCAD CAI/RS CASE/RS IAT
------ooo---OOO---ooo------
Elmar Boye
Michael Ronge <las...@gibts.net> schrieb ...
> auf einem SQL-Server kann man neben Stored Procedures auch
> benutzerdefinierte Funktionen erstellen, die gegenüber SPs einige
> zusätzliche Vorteile besitzen.
> Solange ich mit der VS.NET-IDE (Version 1.1) auf einen SQL-Server 7
> zugreife, sehe ich die Funktionen im Explorer und kann sie mit den
> Assistenten auswählen.
Das kann wohl kaum sein, denn der SQL Server 7 kannte noch
gar keine benutzerdefinierte Funktionen.
> Auf einem SQL-Server 2000 werden die Funktionen nirgendwo angezeigt
> und lassen sich nirgendwo auswählen.
da sollten sie unter "Functions" aufgelistet werden.
Oder hast Du die SQL Server Instanzen verwechselt?!?
Gruss
Elmar
Michael Ronge
> Das kann wohl kaum sein, denn der SQL Server 7 kannte noch
> gar keine benutzerdefinierte Funktionen.
> da sollten sie unter "Functions" aufgelistet werden.
Es gibt überhaupt keinen Ordner Functions
> Oder hast Du die SQL Server Instanzen verwechselt?!?
Nein, definitiv nicht.
Gruß
Michael
Michael Ronge
> Server Explorer unter Data Connections eine Datenbank eintrage die auf
> einem SQL Server 2000 läuft so bekomme ich "Database Diagrams", "Tables",
> "Views", "Stored Procedures" und "Functions".
genauso aus) und erhalter nur Datenbanken, Views und SPs, weder Diagramme
noch Funktionen.
>
> Wenn ich den Vorgang mit einem User wiederhole der nur DataReader ist
> fehlen mir bspw. die Diagramme. Also eventuell solltest du einmal deine
> Berechtigungen auf der Datenbank nachkontrollieren.
Ich habe Systemadmin-Rechte (NT-Authentifizierung) und bin dbo für die DB
und Administrator auf der Entwicklungsmaschine, auf der VS.NET, der IIS und
der SQL-Server laufen.
Kann es sein, dass für die Entwicklung von ASP.NET evtl. nicht meine
eigenen, sondern die Rechte des ASPNET-Benutzers gelten? Allerdings hat ein
Hinzufügen in die Gruppe der DBOwner nichts bewirkt.
Gruß
Michael
Juergen Frieling
>> Das kann wohl kaum sein, denn der SQL Server 7 kannte noch
>> gar keine benutzerdefinierte Funktionen.
> Dafür laufen sie aber bei mir ganz gut ;o)
Wenn's um SQL-Server geht, zweifle nie an Elmars Worten ;-)
UDF sind z.B. in BOL für MS-SQL 2000 unter 'What's new'/'Relational
Database Enhancements' aufgelistet.
Wenn also:
>> Oder hast Du die SQL Server Instanzen verwechselt?!?
>Nein, definitiv nicht.
dann scheint irgend etwas anderes bei Dir mit den beiden durcheinander zu
kommen.
Gruss,
Juergen
Michael Ronge
> Wenn's um SQL-Server geht, zweifle nie an Elmars Worten ;-)
> UDF sind z.B. in BOL für MS-SQL 2000 unter 'What's new'/'Relational
> Database Enhancements' aufgelistet.
mitgeliefert wird, ein SQL-Server 2000 oder 7? Warum identifiziert sie sich
mit SQL-Server 7 im Enterprise Manager?
Und warum werden die Funktionen auf einer MSDE aufgelistet, aber nicht auf
einem Standard Server?
Und was kann durcheinander kommen? Ich habe lediglich eine
Standard-Installation vorgenommen.
Gruß
Michael
Juergen Frieling
> jetzt bringt ihr mich wirklich ins Grübeln. Ist die MSDE, die mit VS
> mitgeliefert wird, ein SQL-Server 2000 oder 7?
Dabei ist bei mir gar keine, aber ein Hinweis mit Link zu 'Microsoft SQL
Server 2000 Service Pack 3'.
> Warum identifiziert sie sich mit SQL-Server 7 im Enterprise Manager?
> Und warum werden die Funktionen auf einer MSDE aufgelistet, aber nicht
> auf einem Standard Server?
Weiss ich von hier aus leider auch nicht :-(
Was steht denn in Systemsteuerung/Software?
Gruss,
Juergen
Elmar Boye
Naja, ich bin auch nur ein Mensch ;-)
>> UDF sind z.B. in BOL für MS-SQL 2000 unter 'What's new'/'Relational
>> Database Enhancements' aufgelistet.
> jetzt bringt ihr mich wirklich ins Grübeln. Ist die MSDE, die mit VS
> mitgeliefert wird, ein SQL-Server 2000 oder 7?
Was da jeweils installiert ist, sollte ein
SELECT @@VERSION
sehr schnell klären.
Bei Visual Studio .NET 2002 MSDE 2000, also SQL Server 2000 kompatibel.
Eine MSDE 1.0/SQL Server 7 gabs beim älteren Visual Studio 6.
Für VS 2003 war da allerdings nichts mehr dabeim sondern via
Download als SP3a zu kriegen, im übrigen immer empfehlenswert
http://www.microsoft.com/sql/downloads/2000/sp3.asp
und neuerdings sogar frei verteilbar:
http://www.microsoft.com/sql/msde/downloads/download.asp
> Und was kann durcheinander kommen? Ich habe lediglich eine
> Standard-Installation vorgenommen.
Dass man den Solution Explorer so schnell durcheinander bringen kann,
glaube ich eher nicht. Schau aber, mal ob die dortigen OLEDB Connection-
Eigenschaften noch passen.
Gruss
Elmar
Peter Koen
>> Also ich weiß ja nicht was du gemacht hast genau, aber wenn ich bei
>> mir im Server Explorer unter Data Connections eine Datenbank eintrage
>> die auf einem SQL Server 2000 läuft so bekomme ich "Database
>> Diagrams", "Tables", "Views", "Stored Procedures" und "Functions".
> Ich verwende den ODBC Driver for SQL Server von VS.NET (mit DSNs sieht
> es genauso aus) und erhalter nur Datenbanken, Views und SPs, weder
> Diagramme noch Funktionen.
Das liegt wohl daran, dass Diagramme und UDFs nicht von ODBC unterstütz
werden, sondern lediglich vom .NET SQL Data Provider und von den
entsprechenden OLE DB Providern
Warum überhaupt ODBC? Außer das es langsam ist und nicht alle Features des
SQL Servers unterstützt finde ich nichts was OLEDB oder SQL.NET nicht auch
könnte :)
Außerdem ist ODBC um einiges langsamer als OLEDB und .NET SQL Data
Provider.
Peter Koen
Wie schon an anderer Stelle erwähnt: Wenn du ODBC nutzt wirst du nie UDFs
finden, weil diese davon einfach nicht unterstützt werden.
Peter Koen
> Hallo Peter,
>> Das liegt wohl daran, dass Diagramme und UDFs nicht von ODBC
>> unterstütz werden, sondern lediglich vom .NET SQL Data Provider und
>> von den entsprechenden OLE DB Providern
>> Warum überhaupt ODBC? Außer das es langsam ist und nicht alle
>> Features des SQL Servers unterstützt finde ich nichts was OLEDB oder
>> SQL.NET nicht auch könnte :)
> das sieht vielversprechend aus. Allerdings bin ich jetzt unsicher, ob
> ich SQL.NET verwende. Ich benutze SQLConnections und SQLDataAdapter.
> Die Einrichtung einer Verbindung sieht so aus wie in der Anlage. Ist
> das SQL.NET oder ODBC?
> Danke für die Antwort bisher.
> Gruß
> Michael
>
>
> begin 666 Bild1.gif
> Attachment saved: D:\xnews\attachments\Bild1.gif
> `
> end
>
>
Nein, das ist OLEDB wenn du den Dialog zu sehen bekommst beim Einrichten
der Verbindung. Das sagt aber noch wenig darüber aus was du in deinem
Code verwendest. Wenn du in deinem Code die SqlXXXXXX Klassen verwendest
dann hast du für den Zugriff den SQL .NET Data Provider.
Michael Ronge
> der Verbindung. Das sagt aber noch wenig darüber aus was du in deinem
> Code verwendest. Wenn du in deinem Code die SqlXXXXXX Klassen verwendest
> dann hast du für den Zugriff den SQL .NET Data Provider.
trotzdem nicht. Irgendwie frustriert mich das. Und ich verstehe immer noch
nicht, warum es auf zwei Maschinen nicht angezeigt wird, auf der dritten
aber doch, obwohl alle drei die gleiche DB verwenden.
Gruß
Michael
Peter Koen
Du benutzt zwar SQL Provider im Code. Aber nutzt du den auch im Server
Explorer?
Dein Screenshot läßt darauf schließen, dass du im Server Explorer OLEDB
nutzt.
Michael Ronge
> Explorer?
>
> Dein Screenshot läßt darauf schließen, dass du im Server Explorer OLEDB
> nutzt.
Gruß
Michael
Elmar Boye
Michael Ronge <las...@gibts.net> schrieb ...
>> Du benutzt zwar SQL Provider im Code. Aber nutzt du den auch im
>> Server Explorer?
>>
>> Dein Screenshot läßt darauf schließen, dass du im Server Explorer
>> OLEDB nutzt.
Ich musste mir zwar erst Dein Bildchen anderswo besorgen, da
ich solche grossen Postings gar nicht erst zu sehen kriege:
Der Server Explorer arbeitet generell mit OleDb. Bestenfalls
kannst Du den MSDAQL Provider (OleDb ODBC Provider) einstellen.
Aber das bringt Dir für die Anwendung und Funktionalität des
Explorers nichts.
Wen man mal im SQL Profiler guckt, wird von VS erstmal nichts weiter als
einiges Trivial SQL abgeschickt. Die Anzeige des Funktions-Teilbaums
im Treeview geschieht, aber zunächst ohne zu prüfen, ob Objekte dafür
vorhanden sind - vermutlich anhand von @@VERSION.
Erst beim Aufklappen werden die möglichen Funktionenstypen einzeln
via sysobjects abgerufen, angezeigt werden nur Funktionen mit
SELECT ANY (permissions(id) & 4096 <> 0), also auf die Du Zugriff hast.
Da sich das erste Handshake sich anscheinend mehr auf Version Kontrolle
bezieht und sehr spekulativ: Da könnte ein Hund begraben liegen, wenn
Du keinen Zugriff auf die dort verwendeten Prozeduren hast. Aber nur eine
Vermutung, weil Access da zum Beispiel Schwierigkeiten hat:
http://support.microsoft.com/?kbid=313298
Falls das nicht weiterführt, schneide mal die Befehle mit und
lasse sie mit der gleichen Benutzeridentifikation durchlaufen.
Und schaue ob dabei Fehler auftreten.
Gruss
Elmar
Michael Ronge
> Falls das nicht weiterführt, schneide mal die Befehle mit und
> lasse sie mit der gleichen Benutzeridentifikation durchlaufen.
> Und schaue ob dabei Fehler auftreten.
Berechtigungen waren gesetzt und soweit nicht, habe ich sie nachgezogen. Die
MSDE, auf der es funktioniert, identifiziert sich auch als SQL Server 2000
(war also eine falsche Annahme von mir). Ich kann keinen Unterschied zu den
anderen Systemen erkennen.
Allerdings ist mir ein anderer Fehler aufgefallen, der möglicherweise eine
Rolle spielen könnte: Beim Versuch, eine DB auf einem SQL-Server zu
erstellen, erhielt ich die Fehlermeldung, die DB könne nicht erstellt
werden. Die Hilfe erklärte, dass mit der Professional Edition nur DBen auf
der Desktop Edition des SQL-Servers erstellt werden können. Für die
Erstellung von DBen auf einem Standard-Server sei die VS.NET Enterprise
Edition notwendig.
Kann der Fehler damit zusammenhängen?
Gruß
Michael
Elmar Boye
Michael Ronge <las...@gibts.net> schrieb ...
>> Falls das nicht weiterführt, schneide mal die Befehle mit und
>> lasse sie mit der gleichen Benutzeridentifikation durchlaufen.
>> Und schaue ob dabei Fehler auftreten.
> leider hat auch das nichts gebracht. Es traten keine Fehler auf, die
> Berechtigungen waren gesetzt und soweit nicht, habe ich sie
> nachgezogen.
Differerieren die Handvoll Anweisungen posten, die entstehen wenn Du
den Zweig für die Verbindung expandierst? Hier kam raus:
SELECT @@version
exec sp_oledb_ro_usrname
USE TEST
select count(*) from sysobjects where name in ( 'dt_adduserobject', 'dt_droppropertiesbyid', 'dt_dropuserobjectbyid',
'dt_generateansiname', 'dt_getobjwithprop', 'dt_getobjwithprop_u', 'dt_getpropertiesbyid', 'dt_getpropertiesbyid_u',
'dt_setpropertybyid', 'dt_setpropertybyid_u', 'dt_verstamp006', 'dt_verstamp007', 'dtproperties' ) and uid = 1
exec dbo.dt_verstamp007
select count(*) from sysobjects where uid = 1 and name in ( 'dt_addtosourcecontrol', 'dt_addtosourcecontrol_u',
'dt_adduserobject_vcs', 'dt_checkinobject', 'dt_checkinobject_u', 'dt_checkoutobject', 'dt_checkoutobject_u', 'dt_displayoaerror',
'dt_displayoaerror_u', 'dt_getpropertiesbyid_vcs', 'dt_getpropertiesbyid_vcs_u', 'dt_isundersourcecontrol',
'dt_isundersourcecontrol_u', 'dt_removefromsourcecontrol', 'dt_validateloginparams', 'dt_validateloginparams_u', 'dt_vcsenabled',
'dt_whocheckedout', 'dt_whocheckedout_u', 'dtproperties' )
exec sp_dboption N'TEST', 'read only'
(Datenbankname war TEST, Anmeldung via SPPI und Konto ist DBO)
> Die MSDE, auf der es funktioniert, identifiziert sich
> auch als SQL Server 2000 (war also eine falsche Annahme von mir).
Das es eine 2000er Ausgabe habe ich jetzt erstmal stillschweigend
angenommen.
> Ich kann keinen Unterschied zu den anderen Systemen erkennen.
Hast Du mehr als eine Instanz installiert und evtl. auch eine
SQL Server 2000 Standard, Enterprise oder Developer Ausgabe darunter?
> Allerdings ist mir ein anderer Fehler aufgefallen, der möglicherweise
> eine Rolle spielen könnte: Beim Versuch, eine DB auf einem SQL-Server
> zu erstellen, erhielt ich die Fehlermeldung, die DB könne nicht
> erstellt werden. Die Hilfe erklärte, dass mit der Professional
> Edition nur DBen auf der Desktop Edition des SQL-Servers erstellt
> werden können. Für die Erstellung von DBen auf einem Standard-Server
> sei die VS.NET Enterprise Edition notwendig.
> Kann der Fehler damit zusammenhängen?
Das glaube ich nicht. Diese Prüfung wird sehr wahrscheinlich erst durch
den Menüpunkt durchgeführt. (Kanns aber nicht testen da ich nunmal die
Enterprise Architect Edition englisch installiert habe).
Gruss
Elmar
Michael Ronge
einen Unterschied zu deinem Posting konnte ich nicht erkennen:
--------------------------
SELECT @@version
exec sp_oledb_ro_usrname
USE Server
select count(*) from sysobjects where name in ( 'dt_adduserobject',
'dt_droppropertiesbyid', 'dt_dropuserobjectbyid', 'dt_generateansiname',
'dt_getobjwithprop', 'dt_getobjwithprop_u', 'dt_getpropertiesbyid',
'dt_getpropertiesbyid_u', 'dt_setpropertybyid', 'dt_setpropertybyid_u',
'dt_verstamp006', 'dt_verstamp007', 'dtproperties' ) and uid = 1
exec dbo.dt_verstamp007
select count(*) from sysobjects where uid = 1 and name in (
'dt_addtosourcecontrol', 'dt_addtosourcecontrol_u', 'dt_adduserobject_vcs',
'dt_checkinobject', 'dt_checkinobject_u', 'dt_checkoutobject',
'dt_checkoutobject_u', 'dt_displayoaerror', 'dt_displayoaerror_u',
'dt_getpropertiesbyid_vcs', 'dt_getpropertiesbyid_vcs_u',
'dt_isundersourcecontrol', 'dt_isundersourcecontrol_u',
'dt_removefromsourcecontrol', 'dt_validateloginparams',
'dt_validateloginparams_u', 'dt_vcsenabled', 'dt_whocheckedout',
'dt_whocheckedout_u', 'dtproperties' )
--------------------------
> Hast Du mehr als eine Instanz installiert und evtl. auch eine
> SQL Server 2000 Standard, Enterprise oder Developer Ausgabe darunter?
Na ja, bei mir sieht es so aus:
Maschine 1: Windows 2003 Server Standard, SQL Server 2000 Standard, VS.NET
Pro.
Maschine 2: Windows 2000 Server Standard, SQL Server 2000 Standard
Maschine 3: Windows XP Pro, MSDE, VS.NET Pro.
Und nur auf Maschine 3 sind die Funktionen zu sehen, wenn auf die lokale
MSDE zugegriffen wird, nicht jedoch wenn auf die DB von Maschine 2
zugegriffen wird. Auf Maschine 1 sind lokal keine Funktionen zu sehen, es
gibt auch keine Verbindung zu den anderen Systemen (getrennte Netze). Auf
allen Maschinen läuft nur eine Instanz des SQL Servers.
Gruß
Michael
Elmar Boye
> einen Unterschied zu deinem Posting konnte ich nicht erkennen:
>
>
>> Hast Du mehr als eine Instanz installiert und evtl. auch eine
>> SQL Server 2000 Standard, Enterprise oder Developer Ausgabe darunter?
> Na ja, bei mir sieht es so aus:
>
> Maschine 1: Windows 2003 Server Standard, SQL Server 2000 Standard,
> VS.NET Pro.
> Maschine 2: Windows 2000 Server Standard, SQL Server 2000 Standard
> Maschine 3: Windows XP Pro, MSDE, VS.NET Pro.
>
> Und nur auf Maschine 3 sind die Funktionen zu sehen, wenn auf die
> lokale MSDE zugegriffen wird, nicht jedoch wenn auf die DB von
> Maschine 2 zugegriffen wird. Auf Maschine 1 sind lokal keine
> Funktionen zu sehen, es gibt auch keine Verbindung zu den anderen
> Systemen (getrennte Netze). Auf allen Maschinen läuft nur eine
> Instanz des SQL Servers.
So langsam gehen mir die Ideen aus -> Das scheint eher ein Fall
für den Microsoft Support zu sein.
Überall gleiches (letztes) Servicepack SP3(a), also
@@VERSION = 8.00.760 oder höher (8.00.818)?
Und eine identische Ausgabe von
SELECT *
FROM master..spt_server_info
WHERE attribute_name = 'SYS_SPROC_VERSION'
(ist Versionsnummer der INSTCAT.SQL)
Gruss
Elmar
Michael Ronge
> @@VERSION = 8.00.760 oder höher (8.00.818)?
> Und eine identische Ausgabe von
> SELECT *
> FROM master..spt_server_info
> WHERE attribute_name = 'SYS_SPROC_VERSION'
> (ist Versionsnummer der INSTCAT.SQL)
auf Maschine 1 und 2 erscheint jeweils:
500 SYS_SPROC_VERSION 8.00.375
also scheint, die INSTCAT.SQL irgendwie anders zu sein. Maschine 3 kann ich
erst morgen testen. Ist das das Problem? Wenn ja, wie löst man es?
Gruß
Michael
Elmar Boye
Michael Ronge <las...@gibts.net> schrieb ...
>> Überall gleiches (letztes) Servicepack SP3(a), also
>> @@VERSION = 8.00.760 oder höher (8.00.818)?
> Ja 8.00.810 auf Maschine 1 und 8.00.760 auf Maschine 2, aber..
810 dürfte ein Hotfix sein, das müsste aber mittlerweile
durch den kumulativen Sicherheitspatch abgedeckt sein:
http://support.microsoft.com/?kbid=815495
>> Und eine identische Ausgabe von
>> SELECT *
>> FROM master..spt_server_info
>> WHERE attribute_name = 'SYS_SPROC_VERSION'
>> (ist Versionsnummer der INSTCAT.SQL)
>
> auf Maschine 1 und 2 erscheint jeweils:
> 500 SYS_SPROC_VERSION 8.00.375
> also scheint, die INSTCAT.SQL irgendwie anders zu sein. Maschine 3
> kann ich erst morgen testen. Ist das das Problem? Wenn ja, wie löst
> man es?
Die INSTCAT.SQL ist im Servicepack wie im MDAC enthalten. Ich habe hier
noch eine 8.00.707 (ist in SP3) und eine 8.00.552 (in MDAC 2.7 SP1), wobei
sich die beiden nur in Kleinigkeiten unterscheiden, die für Dein Problem
aber kaum eine Rolle spielen dürften.
Deine Version (375) scheint aus MDAC 2.6 SP1 zu stammen, prüfe mal welche
MDAC Version auf dem Server da installiert ist. Die Datei selbst hat
einige Differenzen zur letzten (707), aber kriegsentscheidend sollte das
alleine nicht sein...
... ist ohnehin alles schon nach dem berühmten Strohhalm greifen ;-)
Gruss
Elmar
Michael Ronge
die einzige Maschine, auf der es funktioniert (Maschine 3) hat noch den SP 1
(Version 8.00.375). Ansonsten habe ich tatsächlich den Hotfix eingespielt.
Vielleicht sollte ich den SQL Server mal deinstallieren und neu
installieren? Das wäre mein letzter Strohhalm.
Gruß
Michael
Elmar Boye
Michael Ronge <las...@gibts.net> schrieb ...
> die einzige Maschine, auf der es funktioniert (Maschine 3) hat noch
> den SP 1 (Version 8.00.375).
Das ist allerdings reichlich seltsam - hier sind das alles Instanzen
mit SP3a (+ Hotfixes) und es funktioniert.
> Ansonsten habe ich tatsächlich den Hotfix eingespielt.
Installiere zunächst mal die SP3a + MS03-31 (KB815495) erneut.
> Vielleicht sollte ich den SQL Server mal deinstallieren und
> neu installieren? Das wäre mein letzter Strohhalm.
Am Schluss würde ich das zumindest mit einer Instanz mal
probieren.
Gruss
Elmar