[SQL2000 sp4]Simpele query, lastig ODBC probleem

[Massiefje]

Voor een applicatie (dat ik overigens schrijf in C#), moet ik via een ODBC connectie een aantal zaken uitlezen uit een SQL2000 database. Het idee is, dat ik records uit de SQL database lees welke ik in een andere database terugplaats. Als dat gelukt is, schrijf ik een nieuwe status weg naar de SQL database.

Echter, vanwege performance hebben we gekozen om er een service van te maken, die (bijvoorbeeld) 1x per minuut, 10 records overhevelt. Zodra echter de 10 records alle 10 niet toegevoegd kunnen worden, krijgen deze 10 dus ook geen nieuwe status en is het gevolg dus, dat deze 10 elke keer terugkomen in mijn select query en dus elke keer weer falen.

Mijn huidige query is ongeveer zo (even uit mijn hoofd):

SQL:

select top 10 * from tabel
where status is not null and status <> '70'

Wat ik eigenlijk zou willen, is dat ik uit de database 10 random records kan ophalen. Zodat als er 10 stuks gefaald zijn, hij toch lekker door kan draaien.

Ik kan wel random volgordes gebruiken door te sorteren op NEWID(), maar dan sorteert hij binnen dezelfde 10.

Wie heeft er een idee ?

[giMoz]

nee, dat moet je (IMO) niet willen.

wat je wel moet willen IMO is dat je een status bijhoudt met dat die record dus niet toegevoegd kon worden, en dat je ook filtert op die status

SQL:

select top 10 * from tabel 
where status is not null and status <> '70' and status <> 'statusgetal van niet toegevoegd'

en dan kan je later kijken wat je gaat doen (bv. iedere minuut) met de records die niet toegevoegd konden worden.

[ Voor 4% gewijzigd door giMoz op 25-01-2007 10:04 . Reden: 2x hetzelfde zeggen helpt niet. (en typfouten zijn ook niet ok) ]

[Massiefje]

giMoz schreef op donderdag 25 januari 2007 @ 10:02:
nee, dat moet je (IMO) niet willen.

Waarom niet? De status van de record heb ik niet zelf verzonnen. Dit zijn statussen die zijn vastgelegd door mijn opdrachtgever. Ik kan dus eigenlijk niet zomaar extra statussen verzinnen.

Daarbij leek mij dit het makkelijkste en komt uiteindelijk op hetzelfde neer.

Kun je iets specifieker zijn waarom ik dit niet zou moeten willen ?

[giMoz]

omdat als je niets doet met de records die je niet kan toevoegen er daar steeds meer van komen en je na ene tijdje dus ook met random 10 records terug kan krijgen die je niet kon (en nog niet kan) toevoegen.

[xos]

Ik neem aan dat elk record een primary key heeft. Je zou kunnen overwegen een hulptabel te gebruiken waarin je het pk en de status of een insert gelukt is of niet opslaat. Dan kan je die tabel gebruiken om records te selecteren welke nog niet eerder aan de beurt zijn gekomen. Verder kan je eenvoudig een lijstje met records welke mislukt zijn voor je baas/opdrachtgever tevoorschijn toveren.

[lier]

Waarom maak je gebruik van ODBC ?

Misschien een optie om eens naar ADO.NET te kijken ?

giMoz schreef op donderdag 25 januari 2007 @ 10:28:
omdat als je niets doet met de records die je niet kan toevoegen er daar steeds meer van komen en je na ene tijdje dus ook met random 10 records terug kan krijgen die je niet kon (en nog niet kan) toevoegen.

Waarom kan je ze niet toevoegen ?
Moet je niet met logica gaan werken, waarbij je verschillende stadia definieert ?
"niet toe te voegen", "toe te voegen", "toegevoegd", enz.

[ Voor 73% gewijzigd door lier op 25-01-2007 10:33 ]

[Massiefje]

lier schreef op donderdag 25 januari 2007 @ 10:31:
Waarom maak je gebruik van ODBC ?

Misschien een optie om eens naar ADO.NET te kijken ?

[...]

Waarom kan je ze niet toevoegen ?
Moet je niet met logica gaan werken, waarbij je verschillende stadia definieert ?
"niet toe te voegen", "toe te voegen", "toegevoegd", enz.

Dit klinkt voor mij hetzelfde als: waarom ga je met de fiets en niet met de auto ?

Het kan allebei. Dus waarom moeilijk doen als het makkelijk kan ?

Voro wat betreft de logica; de statussen zijn businesslogic en niet technical logic. Oftewel, het gaat om de status van facturen. Betaald, geprint, overgezet, etc etc etc. Een status 'niet toegevoegd' valt daar niet onder en kan ik ook niet kwijt omdat ze daardoor dus facturen in het systeem kwijt zouden kunnen raken.

Wel mooi dat iedereen mooie oplossing aandraagt (de hulptabel vind ik nog wel de mooiste eigenlijk), maar heeft niemand een direct antwoord op mijn vraag, behalve manieren waarop iets beter kan ?

[giMoz]

er zijn wel mogelijkheden met temp tables e.d. maar het blijft een categorie dat het gevolg bestrijding is, en geen probleemoplossing

[lier]

@Massiefje:

Misschien moet je eens terug naar de tekentafel en je functionele ontwerp onder de loop nemen. De meeste antwoorden die je krijgt hebben te maken met het "Wat" en niet met het "Hoe". Hopelijk laat dat bij jou een lampje branden...?

Aardige analogie (fiets/auto),

[giMoz]

leuke analogie, maar vanuit .net met odbc connecten naar een MSSQL2000 database is net zoiets als van je woonkamer naar een verdieping hoger in je huis willen en dan via het huis van je buren gaan en langs de buitenkant via het raam naar binnen klimmen.

Er is een trap binnendoor, waarom zou je die niet gebruiken? Anders dan: ik ben gewend om via de buren te gaan dus blijf ik ook via de buren gaan....

[Massiefje]

giMoz schreef op donderdag 25 januari 2007 @ 11:04:
leuke analogie, maar vanuit .net met odbc connecten naar een MSSQL2000 database is net zoiets als van je woonkamer naar een verdieping hoger in je huis willen en dan via het huis van je buren gaan en langs de buitenkant via het raam naar binnen klimmen.

Er is een trap binnendoor, waarom zou je die niet gebruiken? Anders dan: ik ben gewend om via de buren te gaan dus blijf ik ook via de buren gaan....

Als ze het ADO.NET model eens net zo makkelijk zouden maken, als het ophalen van gegevens via ODBC, zou ik het met je eens zijn.

Maar aangezien ik er (bijna) niet wijs uit kan worden (ook niet na tutorials), leek het mij in dit geval makkelijker en sneller om gewoon via ODBC te connecten, ipv via ADO.NET. Het gaat om een relatief simpele applicatie met maximaal 100 records per keer.

Je kan het makkelijk doen, maar ook moeilijk. Via de buren naar je bovenverdieping is niet makkelijker

[giMoz]

ODBC vs .net native sql connecties
daarin is ODBC nooit sneller en zeker niet makkelijker, (code is bijna gelijk aan elkaar, en je hebt geen windows odbc koppeling meer nodig)
dus beetje raar verhaal, maar goed. Ervaring ergens mee is ook nog steeds een argument voor een keuze.

[lier]

Massiefje schreef op donderdag 25 januari 2007 @ 11:08:Als ze het ADO.NET model eens net zo makkelijk zouden maken, als het ophalen van gegevens via ODBC, zou ik het met je eens zijn.

Maar aangezien ik er (bijna) niet wijs uit kan worden (ook niet na tutorials), leek het mij in dit geval makkelijker en sneller om gewoon via ODBC te connecten, ipv via ADO.NET. Het gaat om een relatief simpele applicatie met maximaal 100 records per keer.

Je kan het makkelijk doen, maar ook moeilijk. Via de buren naar je bovenverdieping is niet makkelijker

Zo zie ik al twee leermomenten: be(ver)oordeel mensen niet te snel, zeker niet als ze jou misschien nog iets kunnen leren. Daarnaast, een moeilijk model ???

Maar ik ben nog steeds benieuwd of je je FO al hebt aangepast ?

[Massiefje]

lier schreef op donderdag 25 januari 2007 @ 11:20:
[...]

Zo zie ik al twee leermomenten: be(ver)oordeel mensen niet te snel, zeker niet als ze jou misschien nog iets kunnen leren. Daarnaast, een moeilijk model ???

Maar ik ben nog steeds benieuwd of je je FO al hebt aangepast ?

Ik be-/veroordeel mensen niet te snel, althans, dat was niet de bedoeling. Ik weet dat wat ik schrijf altijd beter kan. Net als dat wat jij schrijft en wat ome Bill zelf schrijft. Echter, dat was niet mijn vraag.

Ik ben het wel met jullie eens dat het model misschien beter kan, maar aangezien ik een koppeling schrijf tussen 2 (redelijk) dichte paketten, moet ik roeien met de riemen die ik heb. Daarbij speelt ook tijd en geld nog een rol.

Daardoor ga je nadenken of hetgeen ik wil, ook op een andere (misschien minder mooie, maar wel simpelere) manier kan. Ik had die manier gevonden in het random ophalen van de records, waar ik overigens nog steeds geen antwoord op gekregen heb

Hoop dat mijn probleemstelling hiermee wat duidelijker wordt. Ik lees echt wel alles hoor en ik probeer er zoveel mogelijk mee te doen, maar sommige dingen kunnen niet altijd.....

[giMoz]

giMoz in [SQL2000 sp4]Simpele query, lastig ODBC probleem

daar staat waarom jouw randomize oplossing een oplossing is.
Het is een (tijdelijk)gevolgbestrijding, geen structurele oplossing!
Mag je echt geen extra statussen introduceren is een extra tabel ergens met daarin alle id's die niet toegevoegd kunnen worden een nettere oplossing let wel: hoe groter die extra tabel wordt, hoe langzamer je query...

[lier]

Een randomizer is best te realiseren maar is niet echt een oplossing. Wat je beter kan doen is bij het ophalen van je 10 records een status voor deze records te zetten (noem het nu voor het gemak "in behandeling"). Op het moment dat een record verwerkt is, pas je de status van dit record ook aan (laten we zeggen "verwerkt").

Nu hoef je alleen bij het ophalen te controleren of de status van het record niet "in behandeling" is. En volgens mij heb je dan (vrij eenvoudig) je oplossing.

Wat je je ook kan gaan afvragen, waarom kunnen records niet overgezet worden en wat moet met deze records gedaan worden. Allemaal functionele zaken...

Wat voor zware acties worden er eigenlijk uitgevoerd om op 10 records per minuut uit te komen ? (LIER denkt terug aan de dataconversies van 1000+ records per seconde, van SQL 2000 naar SQL 2000 op basis van een C# oplossing... )

giMoz schreef op donderdag 25 januari 2007 @ 11:44:
giMoz in [SQL2000 sp4]Simpele query, lastig ODBC probleem
daar staat waarom jouw randomize oplossing een oplossing is.
Het is een (tijdelijk)gevolgbestrijding, geen structurele oplossing!
Mag je echt geen extra statussen introduceren is een extra tabel ergens met daarin alle id's die niet toegevoegd kunnen worden een nettere oplossing let wel: hoe groter die extra tabel wordt, hoe langzamer je query...

Wat noem jij groot ?
Over hoeveel data hebben we het hier eigenlijk ?

[ Voor 27% gewijzigd door lier op 25-01-2007 11:48 ]

[Massiefje]

giMoz schreef op donderdag 25 januari 2007 @ 11:44:
giMoz in [SQL2000 sp4]Simpele query, lastig ODBC probleem

daar staat waarom jouw randomize oplossing een oplossing is.
Het is een (tijdelijk)gevolgbestrijding, geen structurele oplossing!
Mag je echt geen extra statussen introduceren is een extra tabel ergens met daarin alle id's die niet toegevoegd kunnen worden een nettere oplossing let wel: hoe groter die extra tabel wordt, hoe langzamer je query...

Dat het mogelijk zou kunnen zijn dat ik bij 10 random records, 10 niet toe te voegen records krijg, dat begrijp ik. Als nu echter de query laat lopen, en hij heeft er 10x 1'tje niet toe kunnen voegen, blijft vanaf dat moment de applicatie hangen. Dus is mijn aangedragen oplossing wel beter dan de huidige oplossing

Een tijdelijke tabel zou in principe kunnen natuurlijk, maar dat gaat me gewoon teveel tijd kosten op dit moment. En die tijd heb ik niet.

[Massiefje]

lier schreef op donderdag 25 januari 2007 @ 11:46:
...stuk over waarom het niet handig is, veel van hetzelfde....

Wat voor zware acties worden er eigenlijk uitgevoerd om op 10 records per minuut uit te komen ?
[...]

Wat noem jij groot ?
Over hoeveel data hebben we het hier eigenlijk ?

De acties zijn het samenstellen van de factuur via een COM-object op het trage netwerk van de klant

Bovendien wil ik de 'randomizer' gebruiken voor het ophalen van 10 willekeurige, nog over te zetten facturen, maar elke factuur heeft ook factuur regels. Deze moeten uiteraard ook opgehaald worden en daarna toegevoegd worden aan de zojuist aangemaakte factuur.

Alles dient gecontroleerd en boekhoudkundig juist te gebeuren en dat systeem is vrij traag.

De hoeveelheid data is niet veel. Ga uit van een 2000 facturen per maand, met een gemiddelde van 6 factuurregels ongeveer, vermoed ik.

[farlane]

Massiefje schreef op donderdag 25 januari 2007 @ 11:53:
Als nu echter de query laat lopen, en hij heeft er 10x 1'tje niet toe kunnen voegen, blijft vanaf dat moment de applicatie hangen. Dus is mijn aangedragen oplossing wel beter dan de huidige oplossing

Een tijdelijke tabel zou in principe kunnen natuurlijk, maar dat gaat me gewoon teveel tijd kosten op dit moment. En die tijd heb ik niet.

Met alle respect maar jouw 'oplossing' is geen oplossing zoals al werd aangegeven. Het duurt weliswaar waarschijnlijk langer ( of niet, dat is random ) maar vroeg of laat gaat jouw ding ook hangen.

Maaruh die tabel van mislukte records mag ook in een derde (eigen) database staan.

[Massiefje]

farlane schreef op donderdag 25 januari 2007 @ 12:21:
[...]


Met alle respect maar jouw 'oplossing' is geen oplossing zoals al werd aangegeven. Het duurt weliswaar waarschijnlijk langer ( of niet, dat is random ) maar vroeg of laat gaat jouw ding ook hangen.

Maaruh die tabel van mislukte records mag ook in een derde (eigen) database staan.

Uiteindelijk blijven er idd alleen nog maar 'foutieve' records over. Welke uiteraard wel weggeschreven worden in een logbestandje. Deze kunnen ze dan controleren en aanpassen, waardoor ze de volgende run WEL meegenomen worden.

Wat ik niet begrijp van alle reacties is dat iedereen mij alleen maar kan vertellen wat er mis is aan mijn 'ontwerp' en hoe het beter kan. Het kan beter, met mijn andere 'idee'. Laten we het dan maar geen oplossing noemen. Dat 'idee' is namelijk beter dan hetgeen er nu draait. Toch trekt niemand zich er iets van aan en wil mij blijkbaar niet helpen.

Ik vind dit behoorlijk raar. Zoals net ook al aangegeven; ik weet dat het niet ideaal is, maar beter dan wat ik nu heb. Dus wat let jullie om mij gewoon antwoord te geven...

Begin beetje geirriteerd te worden nu....

[lier]

Massiefje schreef op donderdag 25 januari 2007 @ 12:43:Uiteindelijk blijven er idd alleen nog maar 'foutieve' records over. Welke uiteraard wel weggeschreven worden in een logbestandje. Deze kunnen ze dan controleren en aanpassen, waardoor ze de volgende run WEL meegenomen worden.
...
Begin beetje geirriteerd te worden nu....

Daar ga je nou helemaal de mist in. Je weet namelijk niet of er alleen foutieve records over blijven. Je maakt een structurele fout in je aanpak en verwijt ons ervan dat we je erop wijzen.

Als je alleen antwoord op je vraag wil, kan je het beste (betaalde) hulp inhuren, GoT is een club mensen die elkaar wil helpen, mits je daarvoor open staat.

Oei oei, begin nu bijna een mod rol aan te nemen...

En ten aanzien van de irritatie: niet nodig (wordt je alleen maar moe van !)

Edit:
O ja, randomizen kan je doen met behulp van de methode Rand()

[ Voor 4% gewijzigd door lier op 25-01-2007 12:57 ]

[Massiefje]

Hoevaak moet ik schuld bekennen voordat er iemand begrijpt wat ik zeg ?

Heb al meerdere malen gezegd dat ik WEET dat hte nog beter kan en dat ik WEET dat het niet de beste oplossing is en dat ik LUISTER naar wat jullie zeggen, alleen ik er op dit moment niets mee KAN doen, vanwege tijdgebrek.

Doe ik nou iets verkeerd, of worden mijn berichten verkeerd gelezen ? Modje ? Onafhankelijke mening aub ?

[lier]

Aan jou de schone taak om de opdrachtgever / je baas te overtuigen dat er geen sprake kan zijn van tijdgebrek.

Maar..gelukt met Rand() ?

Als je nou 10 maal een SELECT Rand() * max(technische sleutel) FROM [table] dan heb je je randomizer wel !?

[ Voor 28% gewijzigd door lier op 25-01-2007 13:45 ]

[4of9]

Massiefje schreef op donderdag 25 januari 2007 @ 13:39:
Hoevaak moet ik schuld bekennen voordat er iemand begrijpt wat ik zeg ?

Heb al meerdere malen gezegd dat ik WEET dat hte nog beter kan en dat ik WEET dat het niet de beste oplossing is en dat ik LUISTER naar wat jullie zeggen, alleen ik er op dit moment niets mee KAN doen, vanwege tijdgebrek.

Doe ik nou iets verkeerd, of worden mijn berichten verkeerd gelezen ? Modje ? Onafhankelijke mening aub ?

In de tijd dat je hier aan het discussieren was had je de aangedragen oplossingen al kunnen maken

overigens vind ik het raar dat als er 1 record niet goed gaat ze alle 10 niet goed gaan.
Dit klinkt wel een beetje als een apart ontwerp imo.

Dit soort acties vraagt btw om met transacties te werken.

[giMoz]

@40f9, dat staat er ook niet..
maar goed.
@Massiefje:
je vraagt een oplossing voor de gevolgen van een designfout,
we geven hier allemaal oplssingen die de designfout verhelpen zodat het gevolg ervan ook niet meer optreed.
want met de manier die jij voor ogen hebt kan het gevolg nml nog steeds optreden.
Random is niet een goed oplossing!

[4of9]

giMoz schreef op donderdag 25 januari 2007 @ 15:32:
@40f9, dat staat er ook niet..

Oke idd het staat er niet maar ik vraag me af wat de randvoorwaarden zijn om een insert te laten mislukken en dat dat zo vaak voorkomt dat alle 10 je records mis gaan. En waarom er niet gewoon 1 record per keer gedaan wordt (exclusief, dus de volgende pas als er 1 klaar is, als hij niet gelukt is status er aanhangen en rollbacken en naar de volgende gaan) in samenwerking met een status tabelletje zoals anderen al aangedragen hebben.

[ Voor 11% gewijzigd door 4of9 op 25-01-2007 15:57 ]

[__fred__]

Zou je niet gewoon een nette DTS package schrijven die alles overhevelt van de ene naar de andere database. Die dingen zijn ervoor gemaakt om data tussen data sources over te hevelen. En die dan periodiek uitvoeren.

[lier]

__fred__ schreef op donderdag 25 januari 2007 @ 22:58:
Zou je niet gewoon een nette DTS package schrijven die alles overhevelt van de ene naar de andere database. Die dingen zijn ervoor gemaakt om data tussen data sources over te hevelen. En die dan periodiek uitvoeren.

En wat wil jij precies met je DTS package bereiken ?
Kan je daarmee ook COM operaties uitvoeren ?

De acties zijn het samenstellen van de factuur via een COM-object op het trage netwerk van de klant

Bovendien wil ik de 'randomizer' gebruiken voor het ophalen van 10 willekeurige, nog over te zetten facturen, maar elke factuur heeft ook factuur regels. Deze moeten uiteraard ook opgehaald worden en daarna toegevoegd worden aan de zojuist aangemaakte factuur.

Alles dient gecontroleerd en boekhoudkundig juist te gebeuren en dat systeem is vrij traag.

De hoeveelheid data is niet veel. Ga uit van een 2000 facturen per maand, met een gemiddelde van 6 factuurregels ongeveer, vermoed ik.

[__fred__]

lier schreef op vrijdag 26 januari 2007 @ 09:00:
[...]

En wat wil jij precies met je DTS package bereiken ?
Kan je daarmee ook COM operaties uitvoeren ?


[...]

Dat kan, je kunt middels VB een COM object leegtrekken en zelfs via DTC een distributed transaction opzetten. Kom je wel een beetje in de geavanceerde sfeer. Maar data kopieren van de ene naar de andere bron kan een package in ieder geval bijzonder goed.

[Massiefje]

lier schreef op donderdag 25 januari 2007 @ 13:44:
Aan jou de schone taak om de opdrachtgever / je baas te overtuigen dat er geen sprake kan zijn van tijdgebrek.

Maar..gelukt met Rand() ?

Als je nou 10 maal een SELECT Rand() * max(technische sleutel) FROM [table] dan heb je je randomizer wel !?

Ben eigen baas, dus een baas overtuigen heeft geen zin. Gaat ook niet om de tijd/geld van de klant, maar om mijn eigen tijd.

Hoe dan ook, blijkt wel weer dat er niet goed gelezen wordt hier en dat iedereen toch graag z'n eigen oplossing wil zien. Jammer, maar helaas.

Ga binnenkort in ieder geval met dat Rand() aan de slag, kijken of ik daar iets mee kan.....