Bericht 1 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 09-09-2004 |
| Aan | : | All | MsgID | : | 1458.1 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hallo
Om de geselecteerde items (array) uit een multiselect listbox
i.e. Stored Procedure te verwerken heb ik de iteratie Functies
iter_intlist_to_table en iter_charlist_to_table van Erland
Sommarskog's site gebruikt (voorheen deed ik dit mbv dynamic sql)
in een adp (Access_fe-SQLserver_be) gaat dit niet helemaal goed,
ik krijg wel een aantal records maar lege kolommen... , terwijl
dezelfde Stored Procedure in de Query Analyzer perfect werkt,
ik vermoed dus dat dit n van de beperkingen van een adp is
nu heb ik dit opgelost door user tabelletjes te maken en die in de
SP te joinen, dat werkt goed, de tabellen worden voor de selectie
geleegd en na de selectie gevuld waarna de sp uitgevoerd wordt
(dus niet meer mbv de voornoemde functies)
in een multi useromgeving zou dit problemen kunnen geven als 2 of
meer gebruikers deze tabel gelijk gebruiken, daarom wil ik er een
uniek user id aan geven, hoe kan dit het best, met @@SPID (blijft
die de hele sessie gelijk ?) of beter iets anders gebruiken ?
bvb mijn dank en groetjes --John
Bericht 2 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 11-09-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1458.2 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi John,
> Om de geselecteerde items (array) uit een multiselect listbox
> i.e. Stored Procedure te verwerken heb ik de iteratie Functies
> iter_intlist_to_table en iter_charlist_to_table van Erland
> Sommarskog's site gebruikt (voorheen deed ik dit mbv dynamic sql)
>
> in een adp (Access_fe-SQLserver_be) gaat dit niet helemaal goed,
> ik krijg wel een aantal records maar lege kolommen... , terwijl
> dezelfde Stored Procedure in de Query Analyzer perfect werkt,
> ik vermoed dus dat dit n van de beperkingen van een adp is
Ja, het zou kunnen dat ADP niet goed weet om te gaan met SQL Server functies die een tabel opleveren. Als alternatief zou je kunnen overwegen om een stored procedure te gebruiken die het resultaat van die functie in een tabel zet (eventueel een tijdelijke tabel). Maar als je een andere workaround hebt gevonden die werkt, dan kan dat natuurlijk ook. :-)
> nu heb ik dit opgelost door user tabelletjes te maken en die in de
> SP te joinen, dat werkt goed, de tabellen worden voor de selectie
> geleegd en na de selectie gevuld waarna de sp uitgevoerd wordt
> (dus niet meer mbv de voornoemde functies)
>
> in een multi useromgeving zou dit problemen kunnen geven als 2 of
> meer gebruikers deze tabel gelijk gebruiken, daarom wil ik er een
> uniek user id aan geven, hoe kan dit het best, met @@SPID (blijft
> die de hele sessie gelijk ?) of beter iets anders gebruiken ?
@@SPID blijft gelijk gedurende de gehele connectie. Als je de verbinding verbreekt en weer opbouwt moet je ervan uitgaan dat je een andere @@SPID krijgt. Ik heb gezien dat Access soms extra connecties opent, maar dat was bij eenvoudige schermen, grotendeel door de wizard gemaakt en met weinig VBA code erbij. Ik neem aan dat jij in jouw code zelf bepaalt wanneer een connectie wordt geopend en/of gesloten, dus dan zul jij daar geen last van hebben.
Als userid kun je kiezen tussen de ingebouwde functies USER_ID / USER_NAME (voor userid en username binnen de huidige database), SUSER_SID / SUSER_SNAME (voor loginid en loginnaam binnen de server). Nadelen: meerdere logins kunnen synoniem zijn voor dezelfde database user. En het is ook mogelijk dat meerdere personen dezelfde login gebruiken (door password uitwisselen, maar ook bv. door lidmaatschap in een NT usergroup die bepaalde rechten heeft op SQL Server - zo wordt iedereen die in de NT group Administrators ziet automatisch als "BUILTIN\Administrators" beschouwd.
Een alternatief is om een tijdelijke tabel te gebruiken (als de naam met een # begint zorgt SQL Server voor een tijdelijke tabel). Aan de naam van een tijdelijke tabel voegt SQL Server zelf nog wat extra tekens toe; dan kunnen meerdere mensen (of zelfs meerdere connecties) tegelijk en onafhankelijk van elkaar een tijdelijke tabel gebruiken, allen met dezelfde naam. Je moet dan wel zorgen dat je de connectie in stand houdt, want als de connectie wordt verbroken ruimt SQL Server alle nog bestaande tijdelijke tabellen die bij die connectie horen automatisch op.
Groetjes, Hugo
Bericht 3 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 11-09-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1458.3 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi Hugo
> SUSER_SID / SUSER_SNAME (voor loginid en loginnaam binnen de server)
lijkt me dan aangewezen, omdat we SQL Server Authentication gebruiken
bijkomend voordeel(tje) is dat de selectie bewaard blijft, zodat bij
openen vh form de vorige selectie van de gebruiker er nog is
> Een alternatief is om een tijdelijke tabel te gebruiken
Een temptabel heb ik ook overwogen maar hoe join je die in de SP
bovendien moet je dan toch een UserID hebben of voor elke user
een aparte temptabel, of is daar een oplossing voor
De Functies waren het handigst, die werken als een unieke temptabel
ze zullen in de webapplicatie wel werken, maar in de Access desktop
variant zal ik de workaround moeten gebruiken
Het UserID zullen we ook nodig hebben in een andere tabel waarin
selecties van gekozen WOZnummers zitten samen met een boolean
wederom bedankt voor jou bijdrage !
Groetjes --john
Bericht 4 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 11-09-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1458.4 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi John,
> > Een alternatief is om een tijdelijke tabel te gebruiken
>
> Een temptabel heb ik ook overwogen maar hoe join je die in de SP
Gewoon:
SELECT Kolom1, Kolom2, ... KolomN
FROM JouwTabel
INNER JOIN #TempTabel
ON #TempTabel.SleutelKolom = JouwTabel.SleutelKolom
> bovendien moet je dan toch een UserID hebben of voor elke user
> een aparte temptabel, of is daar een oplossing voor
Een tijdelijke tabel is lokaal voor de connectie. Dat wil zeggen dat je een tijdelijke tabel kunt maken en gebruiken zonder er last van te hebben als in een andere connectie een andere tabel met dezelfde naam wordt gebruikt.
Als je een tool zoals Query Analyser tot je beschikking hebt, open daar dan eens twee vensters in (dan heb je dus ook twee connecties, want QA gebruikt n connectie per venster), beide voor dezelfde database. Kopieer de volgende setjes code in elk van de beide vensers en voer dan de code uit.
(Venster 1)
CREATE TABLE #test (a int)
INSERT #test VALUES(1)
SELECT * FROM #test
(Venster 2)
CREATE TABLE #test (b varchar(20))
INSERT #test VALUES('Venster 2')
SELECT * FROM #test
Zolang de verbinding niet verbroken wordt, kun je nu in beide vensters de SELECT opdracht uitvoeren; dan zie je dat elke connectie zijn "eigen" tabel #test heeft. (In dit geval met verschillende structuur, maar het werkt ook als je ze beide dezelfde structuur geeft).
Als je nu in een derde venster de volgende query uitvoert, dan zie je wat de truuk is die SQL Server toepast om verschillende versies van ogenschijnlijk dezelfde tabel te maken:
SELECT name
FROM tempdb..sysobjects
WHERE name LIKE '#test%'
Het resultaat:
name
--------------------------------------------------
#test_________________________________00000000000E
#test_________________________________000000000014
(Hier ingekort - in werkelijkheid is de tabelnaam 128 tekens lang).
De naam wordt dus uitgevuld met underscores tot 116 tekens en vervolgens wordt een een hexadecimale code van 12 tekens achter geplakt die aangeeft van welke connectie de tabel is.
> De Functies waren het handigst, die werken als een unieke temptabel
> ze zullen in de webapplicatie wel werken, maar in de Access desktop
> variant zal ik de workaround moeten gebruiken
Het is jammer dat ik niet meer weet van Access. Wellicht is er best wel een manier om de functie ook in Access te kunnen gebruiken, maar ik kan je daar helaas niet mee helpen. Welllicht heb je meer geluk als je hier een bericht over post op het MS Developer Applications Forum; daar komen veel Access experts. Het is wel een Engelstalig Forum! Je komt op het MS Developers Applications Forum via onderstaande link:
http://community.compuserve.com/n/pfx/forum.aspx?webtag=ws-msdevappsGroetjes, Hugo
Bericht 5 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 13-09-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1458.5 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi Hugo,
>> Gewoon:
SELECT Kolom1, Kolom2, ... KolomN
FROM JouwTabel
INNER JOIN #TempTabel
ON #TempTabel.SleutelKolom = JouwTabel.SleutelKolom
dat geeft in een adp hetzelfde probleem als de voornoemde functie
het lijkt of een niet fysiek aanwezig object niet binnen huidige
connectie is te vangen, ik zoek het dan ook in die richting, een
adp gaat onderhuids heel speciaal om met connecties, een zoektocht
op Google bevestigd dat vermoeden, dus daar eens mee verder testen
De verdere info was wel erg leerzaam en alles werkt ook perfect in
de QA, alleen werkt het soms helemaal anders in een adp
> Wellicht is er best wel een manier om de functie ook in Access
> te kunnen gebruiken, maar ik kan je daar helaas niet mee helpen.
Ik ga het nog testen binnen een ADO procedure met eigen connectie
en heb zo'n donkerbruin vermoeden dat dat wel gaat lukken ...
> Welllicht heb je meer geluk als je hier een bericht over post op
> MS Developer Applications Forum; daar komen veel Access experts.
Al sedert geruime tijd zitten imho daar niet veel echte experts meer
de meeste ken ik nog van de periode dat ik zelf hulp gaf op dat forum
maar velen zijn daar inmiddels verdwenen, enkele verschijnen nog af-
en-toe, Ken Sheridan is een goeie maar die doet niet veel met adp's
op adp gebied kom je sowieso niet veel experts tegen, ik zie dat
b.v. op microsoft.public.nl.office.access, ik ben daar zo'n beetje
de enigste die een ander daar mee helpt, er is wel een speciaal ms
forum over adp's (niet druk bezocht) en er komt regelmatig wat voor
op andere access fora zoals comp.databases.ms-access, Google is een
goede bron maar je steekt een berg tijd in 't zoeken :-)
ik zoek eerst zelf nog e.e.a. uit en zal de uitkomst terug melden
bedankt voor je hulp!
Groetjes --john
Bericht 6 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 14-09-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1458.6 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi John,
> >> Gewoon:
>
> SELECT Kolom1, Kolom2, ... KolomN
> FROM JouwTabel
> INNER JOIN #TempTabel
> ON #TempTabel.SleutelKolom = JouwTabel.SleutelKolom
>
>
> dat geeft in een adp hetzelfde probleem als de voornoemde functie
Hmmmm. Het lijkt er op dat ADP connecties niet vasthoudt. Als de connectie wordt verbroken en weer hersteld is de tijdelijke tabel intussen weg. Krijg je een foutmelding die aangeeft dat er een tabel ontbreekt? ("Invalid object name '#TempTabel'" - voor zover ADP de boodschap althans niet onderschept).
> > Welllicht heb je meer geluk als je hier een bericht over post op
> > MS Developer Applications Forum; daar komen veel Access experts.
>
> Al sedert geruime tijd zitten imho daar niet veel echte experts meer
> de meeste ken ik nog van de periode dat ik zelf hulp gaf op dat forum
> maar velen zijn daar inmiddels verdwenen, enkele verschijnen nog af-
> en-toe, Ken Sheridan is een goeie maar die doet niet veel met adp's
>
> op adp gebied kom je sowieso niet veel experts tegen, ik zie dat
> b.v. op microsoft.public.nl.office.access, ik ben daar zo'n beetje
> de enigste die een ander daar mee helpt, er is wel een speciaal ms
> forum over adp's (niet druk bezocht) en er komt regelmatig wat voor
> op andere access fora zoals comp.databases.ms-access, Google is een
> goede bron maar je steekt een berg tijd in 't zoeken :-)
Als nieuwsgroepen geen probleem voor je zijn en als je ook niet bang bent voor de Engelse taal, kijk dan ook eens naar de groepen in de hierarchie microsoft.public.sqlserver.*. De meeste van deze groepen zijn druk bezocht, met veel vragen n veel antwoorden. Een overzicht van deze groepen staat op
http://www.microsoft.com/sql/community/newsgroups/default.mspx. Via deze pagina kun je de groepen ook lezen (en zelfs posten) zonder een newsreader te hoeven gebruiken.
Ik heb net de zoek-faciliteit van die webpage gebruikt en gezien dat er verschillende vragen over ADP gesteld en beantwoord worden. Er is hier geen speciale groep voor; de vragen over ADP die ik gevonden heb waren verspreid over verschillende groepen. Groepen die je voor jouw vraag zou kunnen overwegen zijn .clients, .server, .programming of eventueel .connect.
Groetjes, Hugo
Bericht 7 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | John Kopmels (Sysop) | Datum | : | 14-09-2004 |
| Aan | : | Hugo Kornelis | MsgID | : | 1458.7 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi Hugo,
>> Hmmmm. Het lijkt er op dat ADP connecties niet vasthoudt.
Als de connectie wordt verbroken en weer hersteld is de
tijdelijke tabel intussen weg. Krijg je een foutmelding die
aangeeft dat er een tabel ontbreekt?
Dat klopt, een #temptabel bestaat niet meer zodra de sproc klaar is
er komen dan ook meldingen van het soort als jij noemt, maar ook
exotischer meldingen, zolang je de sproc handmatig doet, via de
Access GUI krijg je vaak helemaal geen melding, alleen een leeg rs
Een ADP werkt standaard met de CurrentProject.Connection, dat is
steeds een kopie van de orginele connectie en bovendien een Access
object die de MSDataShape provider gebruikt, ik ben al een paar
keer tegen enige beperkingen aangelopen
Daarvoor in de plaats een eigen ADO connectie opzetten heeft als
voordeel dat er veel meer controle is, maar als nadeel dat er meer
resources verbruikt worden, ik gebruik daarom ook zoveel mogelijk
de default connectie en alleen een aangepast als dat echt nodig is
De Functies werken nu, en lekker snel, alleen wederom binnen een
eigen ADO procedure, de temptabellen geven nog teveel problemen
Op de diverse fora wordt het gebruik van temptabellen dan ook af-
geraden en verwijzen ze naar de in eerste posting genoemde work-
around van een fysieke tabel met een ID kolom bv gevuld met @@spid
maar ik blijf nog wel wat testen en uitkijken naar een oplossing
> Als nieuwsgroepen geen probleem voor je zijn en als je ook niet
> bang bent voor de Engelse taal, kijk dan ook eens naar de groepen
> in de hierarchie microsoft.public.sqlserver.*.
Er staan ook enkele standaard in m'n dagindeling, alleen moet je wat
selectief zijn anders lees je alleen nog maar ipv ook nog te werken,
daarnaast stop ik -net als jij- ook nog wat tijd in het beantwoorden
van (specifieke Access) vragen dat samen vreet tijd als je niet uitkijkt
Het Engels is geen probleem, maar spcifiek doorvragen en uitleggen gaat
voor de meesten (waaronder ook ik) nog het makkelijkst in de eigen taal
ik vind de Google Nieuwsgroepen zoeker zelf nog het beste medium, die
zoekt over *alle* nieuwsgroepen, tot jaren terug, is alleen een kwestie
van de vraag redelijk formuleren en wat met boolean operators googelen
Groetjes --John
Bericht 8 van 8NL Computer Forum ~ SQL & Programmeren | Van | : | Hugo Kornelis | Datum | : | 14-09-2004 |
| Aan | : | John Kopmels (Sysop) | MsgID | : | 1458.8 |
| Onderwerp | : | SQLserver User ID | Forum | : | ws-nlcomputer |
Hoi John,
> >> Hmmmm. Het lijkt er op dat ADP connecties niet vasthoudt.
> Als de connectie wordt verbroken en weer hersteld is de
> tijdelijke tabel intussen weg. Krijg je een foutmelding die
> aangeeft dat er een tabel ontbreekt?
>
> Dat klopt, een #temptabel bestaat niet meer zodra de sproc klaar is
(...)
> Op de diverse fora wordt het gebruik van temptabellen dan ook af-
> geraden en verwijzen ze naar de in eerste posting genoemde work-
> around van een fysieke tabel met een ID kolom bv gevuld met @@spid
Ok, duidelijk. Dan is dat wellicht inderdaad wel de beste oplossing.
Groetjes, Hugo
