Lizenzmanager

OK, dann schreibe ich mal etwas PseudoCode. Die Tabellen und SELECT-Statements sind natürlich wesentlich komplexer, sonst würde ich ja auch keine temp-Tabelle befüllen : So ungefähr kann man sich die StoredProcedure vorstellen : CREATE PROCEDURE spBeispiel AS BEGIN IF OBJECT_ID('tempdb..##tmpTabelle') IS NOT NULL DROP TABLE ##tmpTabelle CREATE TABLE ##tmpTabelle ( Name NVARCHAR(50) NULL, Vorname NVARCHAR(50) NULL, Typ NVARCHAR(20) NULL ) SELECT Name, Vorname, Typ INTO ##tmpTabelle FROM MeineDatenQuelle WHERE Typ IN ('intern', 'extern') END Nun wollte ich mittels zwei Funktionen jeweils 2 Tabellen zurückgeliefert bekommen, die mir einerseits interne und andererseits externe Mitarbeiter ausgibt : CREATE FUNCTION getInterne () RETURNS @table TABLE ( Name NVARCHAR(50) NULL, Vorname NVARCHAR(50) NULL ) AS BEGIN SELECT Name, Vorname INTO @table FROM ##tmpTabelle WHERE Typ = 'interne' RETURN END CREATE FUNCTION getExterne () RETURNS @table TABLE ( Name NVARCHAR(50) NULL, Vorname NVARCHAR(50) NULL ) AS BEGIN SELECT Name, Vorname INTO @table FROM ##tmpTabelle WHERE Typ = 'externe' RETURN END Die Funktionenen verwenden wir so, weil unser SoftwareArchitekt das so vorgibt. Deshalb wollte ich mich einfach daran halten und habe auch hierfür Funktionen verwenden wollen. Nun habe ich das bereits umgestellt auf eine StoredProcedure, die die gesamte Arbeit durchführt, aber eben, ich würde gerne wissen, warum eine Funktion nicht auf eine temp-Tabelle (lesend) zugreifen darf. Dass ich in einer Funktion keine Datenmanipulation oder Datendefinition vornehmen darf, ist mir bewusst. Ich hoffe, dass es durch den Code etwas verständlicher geworden ist ? Gruss und einen guten Start in die neue Woche :)

Vielen Dank zahni, aber ich finde dort keinen Hinweis auf meine Frage.

Hallo zusammen, ich habe feststellen müssen, dass eine Funktion nicht auf eine globale (und natürlich auch lokale) temporäre Tabelle zugreifen kann. Ich habe eine StoredProcedure gebaut, die mir meine gewünschten Daten in eine globale temporäre Tabelle schreibt und kann mit zwei nachgelagerten Funktionen nicht auf diese temporäre Tabelle zugreifen (SELECT * FROM ##tmpTableXYZ). Bei meinen Recherchen habe ich nur ermitteln können, dass das nicht geht. Mich würde aber der Grund dafür interessieren. Weiss das zufällig jemand von euch ? Gruss

Microsoft interessiert nicht, wieviele Leute auf dem SQL Server (oder sonstige Serverprodukte) tatsächlich schaffen, sondern welche darauf arbeiten könnten. Wenn z.B. eine AD-Gruppe "PLM" existiert mit den 12 Benutzern / Maschinen und nur die auf dem Server zugreifen können, dann ist es so, dass nur diese zu lizenzieren sind. Wenn aber in dieser Gruppe noch andere Benutzer drin sind, dann können diese eben zugreifen, auch wenn sie es nie machen. Wichtig ist m.E., dass der Zugriff für nicht lizenzierte (=berechtigte) Benutzer unterbunden wird, um Sicherheit gegenüber Microsoft im Audit zu haben.

naja, so dramatisch wird es wohl nicht werden. Ich gehe davon aus, dass der Hersteller unserer Leasinggeräte so ein Abkommen mit Microsoft gezeichnet hat. Wenn nicht, ja, dann gibt es ja immer noch GGWA

Danke Norbert, dann hätten wir das ja alles geklärt :) ich bin mal gespannt, wie die Entscheidungsträger sich entscheiden .. Schönen (Feier-)Abend

Moin, lass doch mal den SQL Server Profiler laufen, dann solltest du ja sehen, welcher Account wann was macht. Alternativ könntest du auch einen UPDATE-Trigger implementieren, Gruss

Moin, ich bin da nicht sattelfest, versuche mich aber an einer Antwort. Der Link https://technet.microsoft.com/en-us/library/cc645993(SQL.110).aspx sagt folgendes aus : 1GB Maximum memory utilized (per instance of SQL Server Database Engine) aber der Prozess selbst kann ja mit anderen Dingen beschäftigt sein und grösser werden..

jepp Leasing ist ja speziell, wir hier zu lesen ist : http://www.microsoft.com/de-de/licensing/produktlizenzierung/faq/windows-betriebssystem.aspx ob wir die OEM-Lizenzen überhaupt haben, bin ich schon seit drei Monaten am prüfen. Unser Zulieferer war etwas überrascht, dass ich da so pedantisch bin ;) Hierzu muss ja ein Spezialabkommen zwischen Microsoft und dem Leasinggeber vorhanden sein, das liegt mir noch nicht vor, sollte aber bald mal bei mir eintreffen. Das wir die OEM-Lizenzen wirklich trotz Leasings nutzen können, setze ich jetzt einfach mal voraus ..

OK, aber mal angenommen wir kaufen die notwendige Menge CALs ? Wäre dann die Mischung erlaubt ? Danke für euren Einsatz :)

ich mag diese SubQueries nicht mehr besonders und benutze lieber das Konstrukt WITH .. AS WITH z AS ( SELECT SUBSTRING([Ev_Station],1,2) as System_Typ FROM [TEST].[dbo].[EVENTHISTORY] WHERE CAST(substring(CONVERT(varchar(10),[Ev_Time],101),1,2) as numeric) = @paraMonat and cast(substring(CONVERT(varchar(10),[Ev_Time],101),7,4) as numeric) = @paraJahr and Ev_User !='Unbestimmter Benutzer' and Ev_User != 'Guest' --and SUBSTRING([Ev_Station],1,2)='NB' group by [Ev_User],[Ev_Station],SUBSTRING([Ev_Station],1,2) ) SELECT --count (*) as System_Zugriffe_Monat_NB * FROM z macht den Code m.E. nach wesentlich einfacher zu durchschauen. Es geht auch weiter : WITH x AS (SELECT * FROM Tabelle1 WHERE Feld = 1), y AS (SELECT * FROM x WHERE Spalte = 2) SELECT * FROM y Ich hoffe, dass das verständlich und hilfreich war ..

Hallo Dr. Melzer, ich bin mir nicht sicher,ob ich die Frage richtig verstehe, aber antworte nun wie folgt : OEM-Lizenzen beziehen wir im Paket zusammen mit unseren Leasinggeräten. Es handelt sich entweder (kommt auf das Beschaffungsdatum an) um Win7Pro, Win8Pro oder Win8.1Pro. Folgende Volumenlizenzverträge haben wir : Enterprise Agreement (hatten wir, aktuell nciht mehr) Select Plus (aktuell) MPSA (aktuell) Im EA wurden seinerzeit Windows Vista Business U&SA beschafft, sodass wir Windows 7 Enterprise deployed haben. Weitere Windows Client-OS Lizenzen haben wir nicht beschafft.

Moin, bei den CALs ist noch der indirekte Zugriff (Multiplexing) zu berücksichtigen. Szenario : Wenn ihr also zum Beispiel ein Inventarisierungstool habt, dass per Agent das Hard- und SoftwareInventar scannt und das in einem Tool verarbeitet. Dieses Tool schreibt die Daten dann gesammelt in die SQL Server Datenbank über einen Account. In dem Fall müsste dann die Anzahl der gescannten Geräte mit CALs lizenziert werden. Hier ist schnell eine Lizenzierung per Cores sinnvoll. Übrigens ist es möglich und erlaubt beliebig viele SQL Server Instanzen auf der Maschine zu installieren, die Anzahl der SQL Server Lizenzen und SQL Server CALs bleibt unverändert. Und noch wichtig : nicht die Geräte / Benutzer, die auf den SQL Server zugreifen sind zu lizenzieren, sondern diejenigen, die zugreifen können ! Dies gilt auch bei den anderen CALs und Lizenzen. zu der Abwärtskompatibilität : im SQL Server Management Studio kannst du für die jeweilige Datenbank auch die Kompatibilität einstellen und damit u.U. auch schon eine alte SQL Server Instanz einsparen. Gruss, Björn

OK, das mit dem Windows 7 ist ja auch irgendwie klar ;) aber wie ist denn bei Windows 8 Pro ? Darf ich ein Windows8Pro-OEM mit Windows8.1Pro-VL reimagen ? Oder vielleicht anders rum gefragt : welche möglichen Fallstricke existieren allenfalls ? Habt ihr da auch Tipps ? Wie gesagt, ReImage-Recht ist mir irgendwie suspekt... und "handfeste" Informationen finde ich nicht (also PUR oder ProductList) Danke und Gruss

Hallo zusammen, @graf, danke für die Bestätigung; ich hoffe nur, dass wir richtig liegen ;) @norbert, korrekt, die Enterprise CAL Suite wurde mit SA gekauft und ist abgelaufen. Gemäss damals zu Grunde liegenden PURs war damals der Windows Server 2008 R2 aktuell (April 2012). Dass so eine Mischumgebung für mich als Lizenzmanager der Horror ist, ist mir bewusst. Aber die Entscheidungsträger wollen die Möglichkeiten ausloten, die wir haben. Ich schliesse mich aber kofferjunge an. Könntest du bitte deinen letzten Satz aus dem unten eingefügten Zitat näher erläutern ? Wir haben eine vmWare-Umgebung, kein Hyper-V.