[MS SQL] databasename als variabele zonder te executen?

[Verwijderd]

Kan dit op de een of andere manier??

Voor een applicatie maak ik gebruik van twee databases, een voor de accepatie, een voor de productie. In mijn stored procedure is het enige verschil de database name, is het op de een of andere manier mogelijk om de databasename als variabele mee te geven? Zonder dat ik de stored procedure execute met exec()

stored procedure voor acceptatie database

code:

SELECT  [REGIOKANTOOR].ID,
    [REGIOKANTOOR].Naam,
                
FROM       [acceptatie].[dbo].[REGIOKANTOOR] AS [REGIOKANTOOR]

stored procedure voor productie database

code:

SELECT  [REGIOKANTOOR].ID,
    [REGIOKANTOOR].Naam,
                
FROM        [productie].[dbo].[REGIOKANTOOR] AS [REGIOKANTOOR]

[Creepy]

Kleine titelfix gedaan. Zie ook *** Over topictitels in P&W - lezen voor topic openen!!! ***

[ Voor 62% gewijzigd door Creepy op 05-10-2005 13:26 ]

[Equator]

Stored procedures staan toch in je database zelf.. Althans dat is toch de bedoeling bij niet systeemwide sp's
Is ook een stuk makkelijker om later ooit je database naar een andere server te zetten. Dan vergeet je de sp die in master db staan,e n dan werkt je programma niet meer..

Maakt gewoon een optie waarin je selecteerd aan welke database je wilt verbinden, dan kan je de stored procedure exact gelijk houden.
Je hoeft dan alleen de tablenaam op te geven waarvan je de data wilt krijgen..

[ Voor 24% gewijzigd door Equator op 05-10-2005 13:46 ]

[P_de_B]

Dit zou nog mogelijk zijn met ranzige if statements, maar net als CyberJ snap ik niet waarom je dit precies wilt? Verder is het niet mogelijk objectnamen als variabelen te gebruiken.

[Verwijderd]

Sorrie was een beetje onvolledige, ik heb mijn stored procedures in een gewone database staan, deze doet een select in een tabel in een andere database, vandaar dat ik de naam van de database moet meegeven.

Dus ik maak vanuit database a connectie met database b(productie of acceptatie)

[Verwijderd]

P_de_B schreef op woensdag 05 oktober 2005 @ 13:47:
Dit zou nog mogelijk zijn met ranzige if statements, maar net als CyberJ snap ik niet waarom je dit precies wilt? Verder is het niet mogelijk objectnamen als variabelen te gebruiken.

Met de If statements zou het wel kunnen maar vind ik ook een niet erg fraaie oplossing, zou eventueel nog kunnen als het alleen om de from zou staan maar dat kan naar mijn mening niet

[P_de_B]

Nee dat kan inderdaad niet.

Is het niet beter om verschillende procs voor verschillende databases te gebruiken? Eventueel in een ander schema? Je doet dan iets als

EXEC serverA.database.ACCEPTATIE.StoredProcnaam
EXEC serverA.database.PRODUCTIE.StoredProcnaam

Je maakt dus de sp's dubbel aan, met in elke sp de goede verwijzing naar de database.

[Annie]

Ik zou er zelf voor kiezen om de database namen gelijk te houden. De acceptatie en de productie richt je dan in op 2 verschillende instances (of nog beter: servers). Dan hoef je iig geen verschillen aan te brengen in je code.

offtopic:
Je haalt gegevens op uit een andere database, ben je ook bekend met de (mogelijke) gevolgen van cross-database ownership chaining?

[Verwijderd]

Leuke gedachte, maar soms zijn dingen al zoals ze zijn, dat had ik liever ook gehad maar helaas. Heb nog niet echt een mooie opossing gevonden.

[Shezzie]

Waarom bouw je de zaak niet gewoon run-time op? Dus ipv een stored procedure sla je je query op hetzij in een bestand, hetzij als text in een tabel in de SQL server:

SELECT COUNT(*)
FROM LiveDB.dbo.posHeader t1 JOIN BackupDB.dbo.posHeader t2
ON t1.DocumentNumber = t2.DocumentNumber

wordt dan:

SELECT COUNT(*)
FROM {0}.dbo.posHeader t1 JOIN {1}.dbo.posHeader t2
ON t1.DocumentNumber = t2.DocumentNumber

Vervolgens call je de zaak dan(C#):

---

try {
szExportLine = "";
szQueryText = string.Format(LoadQueryFromFile("DUO_DB.SQL"), szDBName1, szDBName2);
cmd = new SqlCommand(szQueryText, sqlcon);
rdr = cmd.ExecuteReader();
if (rdr.HasRows) {
...
// verzin iets leuks
..
} else {
rdr.Close();
return;
}
rdr.Close();
} catch (Exception e) {
LogError(e, szExportLine);
}

return;

---

Ik hoop dat je er iets aan hebt

[whoami]

Da's lekker veilig.
Iedereen die aan die file kan, kan dus die query gaan aanpassen.

[Shezzie]

Tsktsktsk, wat kortzichtig. Het gaat hier niet om de letterlijke code, maar om iemand op ideeen te brengen. Programmeren is niet blind kopieeren maar een een bepaalde methode van denken aanleren.

Over de bovenstaande code:

de files zijn uiteraard gecodeerd, er zit een XOR-berekening over de file heen. de functie LoadQueryFromFile() decodeert de zaak. Simpel he? De software waar het voorbeeld uit is gehaald om Peter op weg te helpen draait trouwens op een rackserver met 2 HTT pentiums en 8GB RAM op de IT-afdeling van een bedrijf dat 280 filialen heeft in heel europa. Alleen de bepaalde mensen en ik weten het hoe/wat/waar. Veilig genoeg.

[eghie]

Shezzie schreef op zaterdag 08 oktober 2005 @ 12:42:
Tsktsktsk, wat kortzichtig. Het gaat hier niet om de letterlijke code, maar om iemand op ideeen te brengen. Programmeren is niet blind kopieeren maar een een bepaalde methode van denken aanleren.

Over de bovenstaande code:

de files zijn uiteraard gecodeerd, er zit een XOR-berekening over de file heen. de functie LoadQueryFromFile() decodeert de zaak. Simpel he? De software waar het voorbeeld uit is gehaald om Peter op weg te helpen draait trouwens op een rackserver met 2 HTT pentiums en 8GB RAM op de IT-afdeling van een bedrijf dat 280 filialen heeft in heel europa. Alleen de bepaalde mensen en ik weten het hoe/wat/waar. Veilig genoeg.

Korzichtig is hij niet echt. Ligt natuurlijk helemaal aan de opbouw van de applicatie. Bij een webapp mag een gebruiker toch niet bij die files komen, dus dan kan het makkelijk in een externe bestand. Bij een app die lokaal draait bij de gebruiker, is het echter een ander verhaal. Daarbij kan de gebruiker gewoon bij de bestanden als hij wil en kan hij ze aanpassen. Met een XOR zou het een beetje te beveiligen zijn, maar is het nog vrij simpel om de boel aan te passen. Ligt natuurlijk aan de doelgroep, maar als er ook gebruikers zijn die kunnen programmeren, zou ik het toch iets anders aanpakken. Bij jullie draait die app op een server waar verder waarschijnlijk niemand bij komt en dan is het wat anders.

Hoe je het dan wel kunt oplossen is bijvoorbeeld door een classe te hebben waar alle query's in staan , zodat het toch onderhoudbaar blijft. Dit moet je dan natuurlijk wel een beetje logisch opbouwen, maar dat spreekt voor zich.

[P_de_B]

Waarom zou je in vredesnaam een query in een file opslaan? Ik ben wel benieuwd naar jullie overwegingen om voor deze oplossing te kiezen.

Ik snap ook niet wat de hardware specificaties te maken hebben met de veiligheid en correctheid van de code?