Om man har ett ADO recordset kan man koppla det till en DBGrid ungefär så här:

SET DBGrid1.DataSource = rstADO

Jag försöker göra samma sak med ett DAO-recordset och det fungerar inte. Jag har provat alla gridar som följer med i VB utan att lyckas. En grid är oprovad dock. Grid32.ocx säger att jag inte har licens för den trots att den finns i listan.

Någon som vet om man kan koppla ett DAO-recordset till en grid på detta sätt? Jag vill av olika anledningar inte använda datakontrollen.

Mvh, Janne

Tipps.
Sluta använda föråldrade DAO och övergå till ADO vilket är ett modernare att använda. Inte bara min rekomendation utan stöds av flertalet (även Microsoft)

Kvalificerat "Bull" DAO 3.6 är det optimala verktyget för Access.
DBGrid32.ocx funkar perfekt tillsammans med DAO

På din CD Vb6 finns en mapp Common/Tools/Vb/Controls/Vbctrols.reg
Lyft över alla ocx :er som finns där till din System32 mapp och kör Vbctrols.reg.

Ado är ett långsamt krångligt djä.."shit" som inte behövs om du håller dig till Access.

"Kvalificerat "Bull" DAO 3.6 är det optimala verktyget för Access."

Det växer snart mossa på DAO. Byt till ADO innan all support upphör.

Om du sedan migrerar till .net världen så är det ADO som gäller.

> Om du sedan migrerar till .net världen

Vem skulle komma på en sån idiotisk idee , att migrerar till VB-net ??

>Byt till ADO innan all support upphör.
Behövs väl ingen support till en produkt som funkat klockrent i över 5 år
Finns hur mycket dokumentation som helst därute till en av MS bästa produkter
Accsess97 DAO 3.6 Jet 4.0. Tillsammans med VB 6 är det de bästa man kan kombinera.

O katten:

> "Accsess97 DAO 3.6 Jet 4.0. Tillsammans med VB 6 är det de bästa man kan kombinera."

Sven, jag som trodde du föredrog Delphi, vilket även det bör kunna använda ADO.


> "Vem skulle komma på en sån idiotisk idee , att migrerar till VB-net ??"

Skrev jag inte men kanske blir tolkningen så då tråden ligger i "Visual Basic - allmänt forum"

ADO gäller även för asp.net, vb.net c#, c++ o.s.v

Utveckling går ej stoppa möjligen bromsa, se ljust på saken det är äntligen fredag.

>Sven, jag som trodde du föredrog Delphi

Stämmer men Delphi och Access är ett djä. strul. ADO befattar jag mig inte med.
Då söker jag andra lösningar. Sanning mina vänner ADO är ett djä.. "shit" som
aldrig skulle ha fötts. Ej hellre ODBC. Kvalificerat "shit" .

Delphi och Paradox är inte heller bra.Jag kör Delphi och DataBaser som man skall
dvs med InterBase.

Just det Roland det är fredag vinet är dekanderat Sven denkanderar.

Fy faen vad jag skall skriva i kväll :-;

Ha det

I morgon 10:00 träffas Vi i Mingelrummet och löser Melodikrysset P4

Skulle vilja se Pelle där.

Ds

Lite kurriosa

Slet nästan håret av mig i början av 90 talet med vb 1.0 då inte Access fanns utan man bara hade Paradox att använda. Det fanns då massor av sjuk kod i Win 3.0 och vb 1.0 vilket då skylldes på Paradox (och Borland) När Win 3.1 och vb 2.0 kom funkade allt kanon med samma version av Paradox. Snacka om Paradoxer

Har haft en del pyssel med DAO men funkade rätt bra och var snabbt, med lite finnes går även ADO snabbt.

Nu föredrar jag att använda ADO vilken jag upplever som mycket stabil vilket därför är min rekomendation till andra.

Tack för era svar (har varit bortrest under helgen).

ADO är inget alternativ för min del. Jag arbetar mot en dBASE-databas och efter mycket experimenterande har jag kommit fram till att det enda sättet att kunna hantera en sådan databas från VB med full funktionalitet är med DAO 3.51. Den delen av diskussionen kan vi därför lämna.

SvenPon, du skriver att DBGrid32.ocx fungerar. Jag gör följande:

<code>
Dim wsp As DAO.Workspace
Dim jdb As DAO.Database
Dim rst As DAO.Recordset
Dim strSQL As String
Set wsp = CreateWorkspace("JetWorkspace", "admin", "", dbUseJet)
Set jdb = wsp.OpenDatabase("C:\DBF", False, False, "dBASE IV;")
strSQL = "SELECT * FROM Tabell"
Set rst = jdb.OpenRecordset(strSQL, dbOpenDynaset)
Set grdData.DataSource = rst
</code>

och får följande felmeddelande. Error 430 Class does not support Automation or does not support expected interface.

//Janne

Snabb analys ,låter som du har fel på din Jetmotor hämta hem SP här hos pelle

http://www.pellesoft.se/login/sysdoc/servpacks.asp

MDAC 2.8 som skall installeras och Jet 4.0 dBase/Access skall installeras.

Amatörer...

Tidigare, innan ADO och Dataenviroment fanns tillgängligt i vb, var det så att man i Visualbasic databand kontroller genom data kontrollen.

För att få DBGrid32.ocx att fungera. Lägger du till en datakontroll på formuläret. I egenskaps fönstret för egenskapen DataSource dyker nu upp namn på din datakontroll i listan.

<code>
Private wsp As DAO.Workspace
Private db As DAO.Database


Private Sub Form_Load()
Dim strSQL As String
Dim rst As DAO.Recordset
strSQL = "SELECT * FROM Tabell"

Set wsp = CreateWorkspace("JetWorkspace", "admin", "", dbUseJet)
Set db = wsp.OpenDatabase("C:\Documents and Settings\Andreas\Mina dokument\FotbollDB.mdb")
Set rst = db.OpenRecordset(strSQL, dbOpenDynaset)
Set Data1.Recordset = rst

End Sub
</code>

SvenPon-> Har provat att uppdatera och det hjälpte tyvärr inte. Får samma felmeddelande.

Andreas-> Som jag skrev tidigare så finns det anledningar till att jag INTE vill använda datakontrollen (tar för stor plats att beskriva varför). Vitsen med den här frågetråden var alltså att få veta om ett befintligt DAO-recordset kan kopplas till någon grid och i så fall vilken.

Mvh, Janne

Mycket märkligt , så här ser det ut i en Setup där jag kör DBGrid32.ocx

Dbgrid32.ocx,$(WinSysPath),$(DLLSelfRegister),$(Shared),6/26/98 7:22:24 PM,525352,5.1.81.4

Jag kör numera Win XP och DAO 3.6 , använder just denna DBGrid därför att
jag kan den utan och innan och den funkar stabilt.

Såg att det finns en DBGrid.reg och en DBGrid32.dep i den mapp jag hänvisade till innan.

I min Components står det Microsoft Databound Control 5.0 SP3. som hänvisar till den ocx :en

Du kan testa att ta hem mitt uppskick Programarkivet:633 Fonder Aktier där använder jag denna ocx.
Om du lägger in den där bifogade ocx:en och dess .osa fil i din systemmapp
så kommer det förmodligen att funka. Problemmet är att det är en tredjparts
komponent från Apix som kom med VB 4.0 . Den är överlägsen MS lösningarna.MS Flexgrid mfl.

Tack för ditt engagemang i frågan SvenPon! Jag tror dock att vi har "gått om varandra" litegrand. Jag har inga problem med registreringen av din favoritgrid DBGrid32.ocx. Den jag inte kunde använda hette Grid32.ocx.

Även i min Components heter den likadant som hos dig så det är nog inte där problemet sitter. Kan det vara så lurigt att det är det underliggande databasformatet (dBASE) som ställer till det?

Kan du skicka ett litet ex på hur du tar fram ett recordset och sedan kopplar det till griden?

Mvh, Janne

Grid.ocx finns också i nämnda mapp med egen .regfil.
Oki skall skicka ett exempel.
dBase har jag aldrig testat, skall se om jag någon sådan fil i min "lådda"
gillar inte att ha olösta prob i skallen :-)

Oki jag blandar ihop DBGrid32.ocx med Grid32.ocx, men den funkar också bra

Kollade på Grid32.ocx,den är är ju riktigt gammal,den får man sk.handmata.
Dvs läsa in via loop från ett rs. Är det den du vill använda ?

Nädå, inte alls. Jag provade med alla gridar jag hittade i Controls. Ingen av dem fick jag att fungera på det sätt jag tänkt. Grid32.ocx kunde jag inte testa pga att den klagade över licensen. Eftersom jag inte kunde testa den så hoppades jag förstås att just den skulle vara den som fungerade.

Just nu kör jag via loop mot en FlexGrid. Jag har klockat både tiden för frågan och tiden för att fylla griden och om jag t.ex ställer en fråga som ger 500 rader och 20 kolumner så tar fyllnaden av griden 4 ggr längre tid än att skapa själva recordsetet. Jag har en känsla av att detta skulle gå väldigt mycket snabbare om jag hittade en grid som kan kopplas mot recordsetet enligt metoden Set Grid.DataSource = RecordSet.

Mvh, Janne

Visst är det så, det går fort som en "höna skiter" Grid32.ocx kan du glömma,den är ute.

Skall Vi satsa snacket på DBGrid32.ocx som du har tillgång till.
Sen analysera vad du får för fel. ERROR och var det uppträder.

Sen skulle jag satsa på en DataKontroll Data1 innan Vi trixar vidare.
Om du kollar på Data1 :s property så har den ett Connect, där kan du välja
aktuell dBase , sen sköter det sig själv.Sen är det bara att ansluta ocx:en till Data1.

När Vi har koll på detta så öppnar/ersätter Vi Data1 enl din metod som ser Ok ut.

-DEt är ju bara att dölja datakontollen. Varför kan du inte använda den?

Synd att du inte kan välja ADO, jag tror mycket av dina problem löses genom att använda en modern teknik.

ADO borde gå lika bra att använda till DBase som DAO.

Roland skrev
>modern teknik. ang ADO

Phuuu. Nu får du ge dig ! ADO är det sämsta skit/dynga
som producerats av så många för så få.Fattar inte varför Ni sitter och tragglar med ADO.
Kavlificerad skitprodukt.

Vad är det som är modernt ???, djävla missmach som är långsamt och krångligt att tillägna sig.
Ungefär som VB.net samma djä.. missmach. Produkt av många kloka hjärnor
som tillsammans skapade ett virrvar.

Hördu Roland Vi tar upp detta om 3 år så får Vi se vem som var klarsyntas !

"Hördu Roland Vi tar upp detta om 3 år så får Vi se vem som var klarsyntas !"

Behöver inte vänta 3 år, om man läser om problemen i denna tråd så inser man snart problemet. DAO är på väg ut och snart kommer stöd saknas helt. I sista MDAC 2.8 är även Jet död.

se inlägg på nyheter här på forumet enligt kopia här nedan

"Microsoft Data Access Components (MDAC) 2.8 installeras samma kärnkomponenter för dataåtkomst som Microsoft SQL Server OLE DB Provider, ODBC Driver. Den slutgiltiga versionen av det distribuerbara installationsprogrammet för MDAC 2.8 installerar samma basuppsättning med MDAC-komponente som ingår i Microsoft Windows Server 2003.

I den här versionen ingår inte Microsoft Jet, Microsoft Jet OLE DB-providern, ODBC-drivrutinen för skrivbordsdatabasrutiner eller Visual FoxPro ODBC-drivrutinen.

Redaktör: Pelle Johansson"

Bara att beklaga. Är ingen älskare av .net men blir nog tvungen att hoppa på där med om man inte vill komma helt på efterkälken.

Skall jag behöva uppleva detta ?

Att det har gått snett, varför kan inte Ni nissar som tar emot allt nytt som dom
religiösa skulle ta emot Jesus. Vissa av de nya linjerna i bl DataBas tex ADO

Är åt helvete fel !!! Ohuuuooooouho ! jag får rysningar när jag ser och läser Ert oförstånd.

Roland skall testa dig !

Är du fullständigt okritisk ,är ADO det bästa som hänt DataBas konstruktörer ?

är det det fullkomliga verktyget, framförallt är det framtid ??? vad tror du ???

"Roland skall testa dig !"
Kör på bara, jag är öppen för diskussion, hoppas Stratocaster kan ha lite nytta av vår diskussion.

"Är du fullständigt okritisk ,är ADO det bästa som hänt DataBas konstruktörer ?"


Nej ADO är inte det ultimata verktyget:
Segare än DAO.
Vissa funktioner är knöligare än i DAO.
Felhanteringen är idiotiskt knölig.
Däremot fungerar hantering mot postlåsningar av andra användare bättre än DAO
Men med erfarenheter mot att köra lösningar utan stöd av MS gör att jag accepterar vissa eländen och väljer ADO.

"...är det det fullkomliga verktyget, framförallt är det framtid ??? vad tror du ???"

Stödet i SQL delen mot programspråk är idiotisk (även i DAO) vilket kräver egen mellanmodul för att skriva någorlunda hyffsad SQL mot.
Här måste man skicka iväg en hel sträng med SQL-satser vilket borde varit löst mycket smidigare.

Närmaste framtiden kommer vara ADO, vad som kommer sedan vet jag ej.
Framtid, tveksamt.
Idén med relationsdatabaser börjar bli lite gammalmodig nu och borde övergå till objektorinetering vilket man mycket sällan hör talas om.

Alltså, ADO inte det fullkomliga verktyget men bäst valet av det som finns nu. tycker Roland. Försök gärna övertyg mig om annat.

Jag skulle nog ha gått över till ADO om möjligheten hade funnits. Inte för att den är bättre/snabbare utan för att min överlevnadsstrategi gentemot MS är att det är lika bra att hänga med i deras nya påhitt annars hamnar man i den situation jag är i nu. Dvs man slutar stödja det.

I mitt specifika problem är det så att jag provat ADO:s alla möjliga connectionvarianter mot dBASE och det är alltid någonting som inte fungerar som det ska. Ett exempel: dBASE-databasen används i ett fleranvändarsystem. När jag kör ADO mot den med de rekommenderade standardinställningarna så låses alla tabeller som ingår i SQL-frågan trots att jag tagit fram ett ADO-recordset som är inställt som read-only.

Jag har råkat på massor av såna här felaktigheter. Inte så konstigt egentligen med tanke på att MS inte tjänar några pengar på att stödja dBASE i ADO. Följden blir att detta dBASE-system nu är under omarbetande till SQL-server och då tjänar ju MS pengar på det :-)

Fram till att det är klart så måste jag i alla fall fortsätta jobba med DAO 3.51 eftersom det är det enda som bevisligen fungerar.

//Janne