|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
can the loading of a large number of records go as quick as in DOSI have build a windows-copy of a DOS-accounting program. All works nice, but the only thing that bothers me is the fact that loading a large number of records is not as quick as in DOS. How can I solve that problem. The data are shown in a MSHFlexGrid and comes from an Access-database. The diference between the DOS-and Windows program is probarbly caused by using a different technic. It looks as DOS reads all the time from and to the hard disk (and thus has only the visible records /data in the memory) as Windows first loads all the records and so has all these records all the time in memory. Am I right and is there a solution for the delaying loading in the windows- program? Thanks Catharinus van der Werf csvanderw***@planet.nl If you are using OBDC/DAO/whatever to read from a MDB then it should be OK.
From your posting it seems that the old program only loaded data as it was needed, why can't you use a similar philosophy here? Secondly is there an apparent delay because the program does not display until the data is loaded? if so move the data load out of the Form_Load, let the program show itself then add then records. There are at least as many different ways to do this as there are programmers, but as you have given us virtually zero information as to how you are doing this now, it's not easy to offer firm suggestions as to how to improve matters. Regards Dave O. Show quoteHide quote "catharinus" <csvanderw***@planet.nl> wrote in message news:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... > Hello > > I have build a windows-copy of a DOS-accounting program. > All works nice, but the only thing that bothers me is the fact > that loading a large number of records is not as quick as in DOS. > How can I solve that problem. The data are shown in a MSHFlexGrid and > comes from an Access-database. > > The diference between the DOS-and Windows program is probarbly caused > by using a different technic. It looks as DOS reads all the time from > and to the hard disk (and thus has only the visible records /data in > the memory) as Windows first loads all the records and so has all > these records all the time in memory. > > Am I right and is there a solution for the delaying loading in the > windows- > program? > Thanks > Catharinus van der Werf > csvanderw***@planet.nl
Show quote
Hide quote
On 15 mei, 14:36, "Dave O." <nob***@nowhere.com> wrote: Oke Dave.> If you are using OBDC/DAO/whatever to read from a MDB then it should be OK. > From your posting it seems that the old program only loaded data as it was > needed, why can't you use a similar philosophy here? > Secondly is there an apparent delay because the program does not display > until the data is loaded? if so move the data load out of the Form_Load, let > the program show itself then add then records. > There are at least as many different ways to do this as there are > programmers, but as you have given us virtually zero information as to how > you are doing this now, it's not easy to offer firm suggestions as to how to > improve matters. > > Regards > Dave O. > > "catharinus" <csvanderw***@planet.nl> wrote in message > > news:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... > > > > > Hello > > > I have build a windows-copy of a DOS-accounting program. > > All works nice, but the only thing that bothers me is the fact > > that loading a large number of records is not as quick as in DOS. > > How can I solve that problem. The data are shown in a MSHFlexGrid and > > comes from an Access-database. > > > The diference between the DOS-and Windows program is probarbly caused > > by using a different technic. It looks as DOS reads all the time from > > and to the hard disk (and thus has only the visible records /data in > > the memory) as Windows first loads all the records and so has all > > these records all the time in memory. > > > Am I right and is there a solution for the delaying loading in the > > windows- > > program? > > Thanks > > Catharinus van der Werf > > csvanderw***@planet.nl- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - you' re right. I didn;t explain enough. I load the data via Form_load and use ADO I open a ADO-connection in which I try to select only the records needed, but that is and stays a problem when having 3000 records, because during the loading I can't exercise any action I do this for example as follows: dim conConnection as adodb.connection dim mrstRecordSet as adodb.recordset set ConConnection=new ADODB.Connection conConnection.ConnectionString = "Provider=Microsoft.jet.OLEDB.4.0; Data Source =\\Database.mdb" conConnection.Open conConnection.ConnectionString set mrstRecordSet=Conconnection.execute("Select * from TABELA order by Number") do while not mrstRecordSet.EOF me.text1(0).text=mrstRecordSet.fields(0).value mrstRecordSet.movenext loop This takes tooo long when I need to load 3000 records. Is there a faster way?? Thanks Catharinus van der Werf csvander***@planet.nl catharinus
I doubt very much if you ever *need* to load 3000 records because unless you are using something like a 50" monitor (in portrait mode!) there is no way that all 3000 can be shown on the screen at once, so only get what's visible. Let's say you can show 30 records on screen at once then all you need to do is keep track of where you are and just load what's needed, grabbing 30 records by ADO should be almost instantaneous. You also may want to look at the database for optimization there, do you index any fields you want to use in a WHERE clause, does the database need regular defragmentation, if so does it get it. If you feel you must load all 3000 and want stop the program from seeming locked, execute a DoEvents every now and then, on a tight loop like you gave, about once every 50 loops would be about the right order of magnitude. Also locking the grid as suggested by Phil is well worth investigating, this is a common trick to speed up responsiveness, for other controls it's common to set the control to Visible=False while loading then reset to True once filled, as the program is not given a chance to redraw the control never actually disappears to the eye but it does to the program. Another method is using the LockWindowUpdate API but to that is not without issues. Dave O. Show quoteHide quote "catharinus" <csvanderw***@planet.nl> wrote in message news:927b121b-dd18-4dd3-a8bb-a8d5fe5665cb@v17g2000vbb.googlegroups.com... > On 15 mei, 14:36, "Dave O." <nob***@nowhere.com> wrote: >> If you are using OBDC/DAO/whatever to read from a MDB then it should be >> OK. >> From your posting it seems that the old program only loaded data as it >> was >> needed, why can't you use a similar philosophy here? >> Secondly is there an apparent delay because the program does not display >> until the data is loaded? if so move the data load out of the Form_Load, >> let >> the program show itself then add then records. >> There are at least as many different ways to do this as there are >> programmers, but as you have given us virtually zero information as to >> how >> you are doing this now, it's not easy to offer firm suggestions as to how >> to >> improve matters. >> >> Regards >> Dave O. >> >> "catharinus" <csvanderw***@planet.nl> wrote in message >> >> news:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... >> >> >> >> > Hello >> >> > I have build a windows-copy of a DOS-accounting program. >> > All works nice, but the only thing that bothers me is the fact >> > that loading a large number of records is not as quick as in DOS. >> > How can I solve that problem. The data are shown in a MSHFlexGrid and >> > comes from an Access-database. >> >> > The diference between the DOS-and Windows program is probarbly caused >> > by using a different technic. It looks as DOS reads all the time from >> > and to the hard disk (and thus has only the visible records /data in >> > the memory) as Windows first loads all the records and so has all >> > these records all the time in memory. >> >> > Am I right and is there a solution for the delaying loading in the >> > windows- >> > program? >> > Thanks >> > Catharinus van der Werf >> > csvanderw***@planet.nl- Tekst uit oorspronkelijk bericht niet >> > weergeven - >> >> - Tekst uit oorspronkelijk bericht weergeven - > > Oke Dave. > > you' re right. I didn;t explain enough. I load the data via Form_load > and use ADO > I open a ADO-connection in which I try to select only the records > needed, but that is > and stays a problem when having 3000 records, because during the > loading I can't exercise > any action > > I do this for example as follows: > > dim conConnection as adodb.connection > dim mrstRecordSet as adodb.recordset > set ConConnection=new ADODB.Connection > conConnection.ConnectionString = "Provider=Microsoft.jet.OLEDB.4.0; > Data Source =\\Database.mdb" > conConnection.Open conConnection.ConnectionString > set mrstRecordSet=Conconnection.execute("Select * from TABELA order by > Number") > do while not mrstRecordSet.EOF > > me.text1(0).text=mrstRecordSet.fields(0).value > mrstRecordSet.movenext > loop > > This takes tooo long when I need to load 3000 records. Is there a > faster way?? > Thanks > > Catharinus van der Werf > csvander***@planet.nl >
Show quote
Hide quote
"catharinus" <csvanderw***@planet.nl> wrote in message Don't use Execute method. It creates forward-only cursor, meaning that you news:927b121b-dd18-4dd3-a8bb-a8d5fe5665cb@v17g2000vbb.googlegroups.com... > Oke Dave. > > you' re right. I didn;t explain enough. I load the data via Form_load > and use ADO > I open a ADO-connection in which I try to select only the records > needed, but that is > and stays a problem when having 3000 records, because during the > loading I can't exercise > any action > > I do this for example as follows: > > dim conConnection as adodb.connection > dim mrstRecordSet as adodb.recordset > set ConConnection=new ADODB.Connection > conConnection.ConnectionString = "Provider=Microsoft.jet.OLEDB.4.0; > Data Source =\\Database.mdb" > conConnection.Open conConnection.ConnectionString > set mrstRecordSet=Conconnection.execute("Select * from TABELA order by > Number") > do while not mrstRecordSet.EOF > > me.text1(0).text=mrstRecordSet.fields(0).value > mrstRecordSet.movenext > loop > > This takes tooo long when I need to load 3000 records. Is there a > faster way?? will get run time errors when you try to move backward after you have moved forward. CacheSize property affects this, allowing you to move backward few rows(the default is 10 rows), but then you get errors after moving back 11 rows. Forward-only cursors are only suitable for reports, or when you want to do some calculations. In these cases you only move forward. As far as I know, but I haven't tested it extensively, the solution is only retrieve what's being viewed, and to do that, you need to use "con.CursorLocation = adUseServer". When you use server side cursors, the records are selected on the server side and stay there. They are retrieved on demand, rs.CacheSize property determine how many are retrieved when scrolling, so set this to 50 or 100 before "rs.Open". When you use "con.CursorLocation = adUseClient", all records are transported to the workstation(in memory and/or temp files), which takes time, so avoid it for large number of records. Also, you need to set CursorType to adOpenKeyset. When you set CursorType, you need to check its value after "rs.Open" because the provider can change it to something else that it supports without warning. This is normal and documented in CursorType property description. In my testing with ADO 2.80, it seems that adOpenKeyset is the only type that Jet provider supports. If you set it to any other type, Jet changes it to adOpenKeyset after you call "rs.Open". So, try the following: dim conConnection as adodb.connection dim mrstRecordSet as adodb.recordset Dim sql As String Dim t As Single set ConConnection=new ADODB.Connection conConnection.ConnectionString = "Provider=Microsoft.jet.OLEDB.4.0; Data Source =\\Database.mdb" ' Use server side conConnection.CursorLocation = adUseServer conConnection.Open conConnection.ConnectionString 'set mrstRecordSet=Conconnection.execute( ' "Select * from TABELA order by Number") sql = "Select * from TABELA order by Number" t = Timer mrstRecordSet.Open sql, conConnection, adOpenKeyset, adLockOptimistic Debug.Print "Time taken: " & Timer - t Debug.Print "RecordCount = " & mrstRecordSet.RecordCount Debug.Print "CursorType = " & mrstRecordSet.CursorType Debug.Print "Supports(adBookmark) = " & mrstRecordSet.Supports(adBookmark) Set MSHFlexGrid1.Recordset = mrstRecordSet In my tests with an MDB file in the local computer, it shows 0 seconds for adUseServer, and 15 ms for adUseClient when selecting 830 records. Here is the code I am using: Option Explicit Private Sub Command1_Click() Dim con As ADODB.Connection Dim rs As ADODB.Recordset Dim ConStr As String Dim sql As String Dim t As Single Const sDBFileName As String = "C:\Test\NWIND2000.MDB" ConStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & sDBFileName Set con = New ADODB.Connection Debug.Print con.Version con.CursorLocation = adUseServer con.Open ConStr Set rs = New ADODB.Recordset sql = "SELECT * FROM Orders" Debug.Print "sql = " & sql t = Timer rs.Open sql, con, adOpenKeyset, adLockOptimistic Debug.Print "Time taken: " & Timer - t Debug.Print "RecordCount = " & rs.RecordCount Debug.Print "CursorType = " & rs.CursorType Debug.Print "Supports(adBookmark) = " & rs.Supports(adBookmark) rs.Close con.Close Set rs = Nothing Set con = Nothing End Sub Finally, what bound control you are using matters. It's possible that the particular bound control that you are using is making requests to retrieve everything at once, creating delays. If this is the case, try another bound control, or third party controls. I don't know if MSHFlexGrid supports this, but I think that True DBGrid supports it: http://www.componentone.com/SuperProducts/StudioActiveX/ http://www.componentone.com/
Show quote
Hide quote
On 15 mei, 18:26, "Nobody" <nob***@nobody.com> wrote: Hello Nobody> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:927b121b-dd18-4dd3-a8bb-a8d5fe5665cb@v17g2000vbb.googlegroups.com... > > > > > > > Oke Dave. > > > you' re right. I didn;t explain enough. I load the data via Form_load > > and use ADO > > I open a ADO-connection in which I try to select only the records > > needed, but that is > > and stays a problem when having 3000 records, because during the > > loading I can't exercise > > any action > > > I do this for example as follows: > > > dim conConnection as adodb.connection > > dim mrstRecordSet as adodb.recordset > > set ConConnection=new ADODB.Connection > > conConnection.ConnectionString = "Provider=Microsoft.jet.OLEDB.4.0; > > Data Source =\\Database.mdb" > > conConnection.Open conConnection.ConnectionString > > set mrstRecordSet=Conconnection.execute("Select * from TABELA order by > > Number") > > do while not mrstRecordSet.EOF > > > me.text1(0).text=mrstRecordSet.fields(0).value > > mrstRecordSet.movenext > > loop > > > This takes tooo long when I need to load 3000 records. Is there a > > faster way?? > > Don't use Execute method. It creates forward-only cursor, meaning that you > will get run time errors when you try to move backward after you have moved > forward. CacheSize property affects this, allowing you to move backward few > rows(the default is 10 rows), but then you get errors after moving back 11 > rows. Forward-only cursors are only suitable for reports, or when you want > to do some calculations. In these cases you only move forward. > > As far as I know, but I haven't tested it extensively, the solution is only > retrieve what's being viewed, and to do that, you need to use > "con.CursorLocation = adUseServer". When you use server side cursors, the > records are selected on the server side and stay there. They are retrieved > on demand, rs.CacheSize property determine how many are retrieved when > scrolling, so set this to 50 or 100 before "rs.Open". When you use > "con.CursorLocation = adUseClient", all records are transported to the > workstation(in memory and/or temp files), which takes time, so avoid it for > large number of records. > > Also, you need to set CursorType to adOpenKeyset. When you set CursorType, > you need to check its value after "rs.Open" because the provider can change > it to something else that it supports without warning. This is normal and > documented in CursorType property description. In my testing with ADO 2.80, > it seems that adOpenKeyset is the only type that Jet provider supports. If > you set it to any other type, Jet changes it to adOpenKeyset after you call > "rs.Open". > > So, try the following: > > dim conConnection as adodb.connection > dim mrstRecordSet as adodb.recordset > Dim sql As String > Dim t As Single > > set ConConnection=new ADODB.Connection > conConnection.ConnectionString = "Provider=Microsoft.jet.OLEDB.4.0; > Data Source =\\Database.mdb" > ' Use server side > conConnection.CursorLocation = adUseServer > conConnection.Open conConnection.ConnectionString > 'set mrstRecordSet=Conconnection.execute( > ' "Select * from TABELA order by Number") > > sql = "Select * from TABELA order by Number" > t = Timer > mrstRecordSet.Open sql, conConnection, adOpenKeyset, adLockOptimistic > Debug.Print "Time taken: " & Timer - t > Debug.Print "RecordCount = " & mrstRecordSet.RecordCount > Debug.Print "CursorType = " & mrstRecordSet.CursorType > Debug.Print "Supports(adBookmark) = " & mrstRecordSet.Supports(adBookmark) > > Set MSHFlexGrid1.Recordset = mrstRecordSet > > In my tests with an MDB file in the local computer, it shows 0 seconds for > adUseServer, and 15 ms for adUseClient when selecting 830 records. Here is > the code I am using: > > Option Explicit > > Private Sub Command1_Click() > Dim con As ADODB.Connection > Dim rs As ADODB.Recordset > Dim ConStr As String > Dim sql As String > Dim t As Single > > Const sDBFileName As String = "C:\Test\NWIND2000.MDB" > > ConStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & sDBFileName > Set con = New ADODB.Connection > Debug.Print con.Version > con.CursorLocation = adUseServer > con.Open ConStr > > Set rs = New ADODB.Recordset > > sql = "SELECT * FROM Orders" > Debug.Print "sql = " & sql > > t = Timer > rs.Open sql, con, adOpenKeyset, adLockOptimistic > Debug.Print "Time taken: " & Timer - t > Debug.Print "RecordCount = " & rs.RecordCount > Debug.Print "CursorType = " & rs.CursorType > Debug.Print "Supports(adBookmark) = " & rs.Supports(adBookmark) > > rs.Close > con.Close > > Set rs = Nothing > Set con = Nothing > > End Sub > > Finally, what bound control you are using matters. It's possible that the > particular bound control that you are using is making requests to retrieve > everything at once, creating delays. If this is the case, try another bound > control, or third party controls. I don't know if MSHFlexGrid supports this, > but I think that True DBGrid supports it: > > http://www.componentone.com/SuperProducts/StudioActiveX/http://www.componentone.com/- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - thanks for your work, but I don;t see any code that fill the flexgrid Or am I wrong Catharinus "catharinus" <csvanderw***@planet.nl> wrote in message This line:news:4be91837-75b2-403a-9185-ef213d20c8ae@n4g2000vba.googlegroups.com... > thanks for your work, but I don;t see any code that fill the flexgrid Set MSHFlexGrid1.Recordset = mrstRecordSet On 15 mei, 19:32, "Nobody" <nob***@nobody.com> wrote: I thought so, but I don't see anytthing> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:4be91837-75b2-403a-9185-ef213d20c8ae@n4g2000vba.googlegroups.com... > > > thanks for your work, but I don;t see any code that fill the flexgrid > > This line: > > Set MSHFlexGrid1.Recordset = mrstRecordSet how does the program know which record field should be in what MSHFlexg.fields I used with MSHFLexGrid .TextMatrix(I, 1) = mrstcurrentrecord.Fields ("Field27").Value .TextMatrix(I, 2) = mrstcurrentrecord.Fields ("Field2").Value .TextMatrix(I, 3) = mrstcurrentrecord.Fields ("Field3").Value .TextMatrix(I, 4) = mrstcurrentrecord.Fields ("Field4").Value .TextMatrix(I, 5) = mrstcurrentrecord.Fields ("Field5").Value End With But that is wrong I suppose Thanks Catharinus "catharinus" <csvanderw***@planet.nl> schrieb im Newsbeitrag In that case, you've probably not commented out the lines innews:bf29517e-5f8c-4043-9880-e9c0a09bcaf2@s20g2000vbp.googlegroups.com... > > Set MSHFlexGrid1.Recordset = mrstRecordSet > > I thought so, but I don't see anytthing Nobodys post, which close the Cnn and the Rs, so you apparently have passed "Nothing" to your Grids-DataSource. So please comment out...: rs.Close con.Close Set rs = Nothing Set con = Nothing ....in Nobodys example. Aside from that, I'm really curious what your pure Rs-Select timings are... Please post them with adUseClient - since adUseServer will not give you the right picture about the real stress that's going on behind the scenes inside the JetEngine to deliver a Select (including the Order By) "fully". Maybe - since you posted that you are using an Order By - the Column(s) on which you perform your Order are not properly indexed (please ensure, that in case of multiple Order-Columns, you also define a MultiColumn-Index). Another reason (in case your 3000er Select is really the culprit) could be, that you perform this Select against a table with - let's say - 150Columns <g>. Are you working by any chance in these Column-ranges? Olaf "Nobody" <nob***@nobody.com> schrieb im Newsbeitrag And if you include that line into your timing, then thenews:uSUoeMY1JHA.4288@TK2MSFTNGP04.phx.gbl... > "catharinus" <csvanderw***@planet.nl> wrote in message > news:4be91837-75b2-403a-9185-ef213d20c8ae@n4g2000vba.googlegroups.com... > > thanks for your work, but I don;t see any code that fill the flexgrid > > This line: > > Set MSHFlexGrid1.Recordset = mrstRecordSet whole thing comes out with: adUseServer 15ms for: "Select * From Orders" (830 Rec x 14 Cols) 18ms for: "Select * From [Order Details]" (2155 Rec x 5 Cols) adUseClient 18ms for: "Select * From Orders" (830 Rec x 14 Cols) 19ms for: "Select * From [Order Details]" (2155 Rec x 5 Cols) So, not that much of a difference then between adUseClient and adUseServer (at least in case of the HFlex, where the underlying Rs finally has "to deliver" in either case). Here the timings (including visualization) for my preferred mode (adUseClient) against the VB6-DataGrid (using Set DataGrid1.DataSource = Rs): adUseClient 9.1ms for: "Select * From Orders" (830 Rec x 14 Cols) 8.5ms for: "Select * From [Order Details]" (2155 Rec x 5 Cols) Speaking for myself, I prefer adUseClient because it behaves more "deterministic" - you can be sure, that you got-what-you- requested (completely ...+ the Recordcount is always valid - no "shifted DB-access later on" when accessing your Rs to really retrieve the data + less "ping-pong" on the Network-protocols + more stability when working against an *.mdb on a Share and more scalability when working against a real Server-Engine). I mean, there's a reason why they removed the server-cursors from ADO.NET (DataSets). That does not mean, that adUseServer is a bad thing - it's just not the mode which is preferred nowadays. Olaf "Schmidt" <s**@online.de> wrote in message There are certain situations when RecordCount property is always valid. From news:OQrV7mY1JHA.1864@TK2MSFTNGP02.phx.gbl... > > the Recordcount is always valid - RecordCount property help(formatted for easy reading): The RecordCount property will return: * -1 for a forward-only cursor * The actual count for a static or keyset cursor * Either -1 or the actual count for a dynamic cursor So if you are using a static or keyset cursor, and assuming that the provider supports it, you get the actual count. Also, from the help: If the Recordset object supports approximate positioning or bookmarks-that is, Supports (adApproxPosition) or Supports (adBookmark), respectively, return True-this value will be the exact number of records in the Recordset, regardless of whether it has been fully populated. So if one does this test after rs.Open, then RecordCount is always valid: rs.Open .... If Not (rs.Supports(adApproxPosition) And rs.Supports(adBookmark)) Then ' RecordCount is not always valid rs.Close MsgBox "Current DB Server is not supported, please change the connection string." Exit Sub End If ' RecordCount is always valid Debug.Print "RecordCount = " & rs.RecordCount
Show quote
Hide quote
"Nobody" <nob***@nobody.com> schrieb im Newsbeitrag Yep - but this "rest of uncertainty" (depending on the Rs-news:eHE0Z2Y1JHA.6056@TK2MSFTNGP03.phx.gbl... > "Schmidt" <s**@online.de> wrote in message > news:OQrV7mY1JHA.1864@TK2MSFTNGP02.phx.gbl... > > > > the Recordcount is always valid - > > There are certain situations when RecordCount property > is always valid. > From RecordCount property help(formatted for easy reading): > The RecordCount property will return: > > * -1 for a forward-only cursor > * The actual count for a static or keyset cursor > * Either -1 or the actual count for a dynamic cursor OpenMode - and maybe also a bit on the OLEDB-provider that comes with your DB-Engine) is only there, if you are working in adUseServer-Mode. In case of adUseClient you can always be sure. I mean - in most cases (if your GUI is designed properly and if you work in "don't select unnecessary data"-mode ;-)) you will have to read your selected data sooner or later from your Rs (to populate your GUI). Then why not Select the damn thing completely already in the first place (and let the server alone after that)? And especially in case of the larger, real Serverengines... Rs-RemoteCursors do bind serverside resources (the serverside cursor which needs to remain "open and remotable" at any time from your not yet fully populated Rs "down there"). Now imagine 300 concurrent clients, and each of these clients has this typical "everything visible in one Form" CRM-interface opened <g>, containing 10-15 opened (and serverside-cursor- based) Recordsets there. That's the scenario which affects serverperformance and scalability then. In short, you don't lose much in case you use clientside cursors, but you can gain a lot (over-all) IMO. Olaf "Schmidt" <s**@online.de> wrote in message You are right. With many users, server side would tax the server and would news:OK%23XfdZ1JHA.4520@TK2MSFTNGP05.phx.gbl... > And especially in case of the larger, real Serverengines... > Rs-RemoteCursors do bind serverside resources (the serverside > cursor which needs to remain "open and remotable" at any time > from your not yet fully populated Rs "down there"). > Now imagine 300 concurrent clients, and each of these clients > has this typical "everything visible in one Form" CRM-interface > opened <g>, containing 10-15 opened (and serverside-cursor- > based) Recordsets there. be unpractical. In any case, viewing tens of thousands of records at once is a bad idea because the user can't read them all. "Filter as you type" is what they think about when they want to see many records, and this can be done by "WHERE field1 LIKE 'A*'", or by using rs.Filter property if the record count is not too large. Besides the suggestions so far, I am not sure if Jet Engine is optimized for
server side, because it's file based and there is no real server side. You may want to test against a DB server to see what difference it makes. Here is a list of database servers, some of which are free: http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems On 15 mei, 20:53, "Nobody" <nob***@nobody.com> wrote: things are al littel too complicated for me at this moment.> Besides the suggestions so far, I am not sure if Jet Engine is optimized for > server side, because it's file based and there is no real server side. You > may want to test against a DB server to see what difference it makes. Here > is a list of database servers, some of which are free: > > http://en.wikipedia.org/wiki/Comparison_of_relational_database_manage... you suggested mshflexgrid1.recordset=mrstcurrentrecordset But in fact I am trying to do the following mshflexgrid1.TextMatrix(I, 0) = mrstcurrentrecord.Fields ("Field1").Value mshflexgrid1.TextMatrix(I, 1) = mrstcurrentrecord.Fields ("Field27").Value mshflexgrid1.TextMatrix(I, 2) = mrstcurrentrecord.Fields ("Field2").Value mshflexgrid1.TextMatrix(I, 3) = mrstcurrentrecord.Fields ("Field3").Value mshflexgrid1.TextMatrix(I, 4) = mrstcurrentrecord.Fields ("Field4").Value mshflexgrid1..TextMatrix(I, 5) = mrstcurrentrecord.Fields ("Field5").Value So ua I want to bring field27 into textmatrix(1) Is that possible with the on-line code or do I need to insert extra code?? Thanks
Show quote
Hide quote
"catharinus" <csvanderw***@planet.nl> wrote in message That's not what I suggested. There is a missing "Set" before mshflexgrid1 in news:733163b8-2035-4c75-af67-2665346fd290@q2g2000vbr.googlegroups.com... > On 15 mei, 20:53, "Nobody" <nob***@nobody.com> wrote: >> Besides the suggestions so far, I am not sure if Jet Engine is optimized >> for >> server side, because it's file based and there is no real server side. >> You >> may want to test against a DB server to see what difference it makes. >> Here >> is a list of database servers, some of which are free: >> >> http://en.wikipedia.org/wiki/Comparison_of_relational_database_manage... > > things are al littel too complicated for me at this moment. > you suggested mshflexgrid1.recordset=mrstcurrentrecordset the line above. You need to use "Set" with objects. As I said on another reply, using "Set" is faster than looping and adding records. If you want to only use certain fields, then specify them in the SQL statement. Example: sql = "Select Field1,Field27,Field2,Field3,Field4,Field5 from TABELA order by Number"
Show quote
Hide quote
"Nobody" <nob***@nobody.com> wrote in message Also, if you want a field to be in the RecordSet, but not visible in the news:efqU1nZ1JHA.5684@TK2MSFTNGP04.phx.gbl... > "catharinus" <csvanderw***@planet.nl> wrote in message > news:733163b8-2035-4c75-af67-2665346fd290@q2g2000vbr.googlegroups.com... >> On 15 mei, 20:53, "Nobody" <nob***@nobody.com> wrote: >>> Besides the suggestions so far, I am not sure if Jet Engine is optimized >>> for >>> server side, because it's file based and there is no real server side. >>> You >>> may want to test against a DB server to see what difference it makes. >>> Here >>> is a list of database servers, some of which are free: >>> >>> http://en.wikipedia.org/wiki/Comparison_of_relational_database_manage... >> >> things are al littel too complicated for me at this moment. >> you suggested mshflexgrid1.recordset=mrstcurrentrecordset > > That's not what I suggested. There is a missing "Set" before mshflexgrid1 > in the line above. You need to use "Set" with objects. > > As I said on another reply, using "Set" is faster than looping and adding > records. If you want to only use certain fields, then specify them in the > SQL statement. Example: > > sql = "Select Field1,Field27,Field2,Field3,Field4,Field5 from TABELA order > by Number" grid, set ColWidth property of the grid to 0, this makes it invisible.
Show quote
Hide quote
On 15 mei, 22:15, "Nobody" <nob***@nobody.com> wrote: OKE Nobody> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:733163b8-2035-4c75-af67-2665346fd290@q2g2000vbr.googlegroups.com... > > > On 15 mei, 20:53, "Nobody" <nob***@nobody.com> wrote: > >> Besides the suggestions so far, I am not sure if Jet Engine is optimized > >> for > >> server side, because it's file based and there is no real server side. > >> You > >> may want to test against a DB server to see what difference it makes. > >> Here > >> is a list of database servers, some of which are free: > > >>http://en.wikipedia.org/wiki/Comparison_of_relational_database_manage... > > > things are al littel too complicated for me at this moment. > > you suggested mshflexgrid1.recordset=mrstcurrentrecordset > > That's not what I suggested. There is a missing "Set" before mshflexgrid1 in > the line above. You need to use "Set" with objects. > > As I said on another reply, using "Set" is faster than looping and adding > records. If you want to only use certain fields, then specify them in the > SQL statement. Example: > > sql = "Select Field1,Field27,Field2,Field3,Field4,Field5 from TABELA order > by Number" thanks, I already hoped that.
Show quote
Hide quote
On 15 mei, 22:15, "Nobody" <nob***@nobody.com> wrote: Thanks, I got it working. and it's working fast. Thanks again.> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:733163b8-2035-4c75-af67-2665346fd290@q2g2000vbr.googlegroups.com... > > > On 15 mei, 20:53, "Nobody" <nob***@nobody.com> wrote: > >> Besides the suggestions so far, I am not sure if Jet Engine is optimized > >> for > >> server side, because it's file based and there is no real server side. > >> You > >> may want to test against a DB server to see what difference it makes. > >> Here > >> is a list of database servers, some of which are free: > > >>http://en.wikipedia.org/wiki/Comparison_of_relational_database_manage... > > > things are al littel too complicated for me at this moment. > > you suggested mshflexgrid1.recordset=mrstcurrentrecordset > > That's not what I suggested. There is a missing "Set" before mshflexgrid1 in > the line above. You need to use "Set" with objects. > > As I said on another reply, using "Set" is faster than looping and adding > records. If you want to only use certain fields, then specify them in the > SQL statement. Example: > > sql = "Select Field1,Field27,Field2,Field3,Field4,Field5 from TABELA order > by Number" But is it possible to speed up the filling of a listview faster by using somethig like this as well? I use do while not mrstcurrentrecord.eof lstview1.listitems.text=mrstcurrentrecord.fields(0).value mrstcrurrentrecord.movenext loop to fill a listview. Hope this can be speeded up as well? thanks Catharinus van der Werf csvanderw***@planet.nl "catharinus" <csvanderw***@planet.nl> wrote in message Try:news:c9dd3f40-2119-40d6-83c8-29a2d9d7283a@s28g2000vbp.googlegroups.com... > Thanks, I got it working. and it's working fast. Thanks again. > But is it possible to speed up the filling of a listview faster by > using somethig like this as well? I use > do while not mrstcurrentrecord.eof > lstview1.listitems.text=mrstcurrentrecord.fields(0).value > mrstcrurrentrecord.movenext > loop > to fill a listview. Hope this can be speeded up as well? ListView1.Visible = False ' Fill the ListView here ListView1.Visible = True
Show quote
Hide quote
On 16 mei, 14:35, "Nobody" <nob***@nobody.com> wrote: Thanks> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:c9dd3f40-2119-40d6-83c8-29a2d9d7283a@s28g2000vbp.googlegroups.com... > > > Thanks, I got it working. and it's working fast. Thanks again. > > But is it possible to speed up the filling of a listview faster by > > using somethig like this as well? I use > > do while not mrstcurrentrecord.eof > > lstview1.listitems.text=mrstcurrentrecord.fields(0).value > > mrstcrurrentrecord.movenext > > loop > > to fill a listview. Hope this can be speeded up as well? > > Try: > > ListView1.Visible = False > ' Fill the ListView here > ListView1.Visible = True it doesn't do much so there is not something like recordset in listview? that's ashame Catharinus The windows API supports a mode of ListView called virtual ListView control,
the VB6 control doesn't utilize it. Basically, it's the same as a regular ListView, but the data is not stored in the ListView, only the displayed information, so it's much faster. Here is a VB6 sample: http://www.mvps.org/vbvision/Sample_Projects.htm#Virtual_ListView_Demo Make sure that you are looking at "Virtual ListView Demo.zip (19KB)", not "Virtual Listbox Demo.zip (34KB)". When you download the sample, it has a debugging library reference missing. You can download it(the link is in the sample description), but you should not use it in the released version. You have to go to Project properties, Make tab, at the bottom, under "Conditional Compilation Arguments", set DEBUGWINDOWPROC to 0. When you set it to 0, you don't need the debugging library, but without it, the IDE might crash if there is a run time error in the windows procedure.
Show quote
Hide quote
On 16 mei, 15:34, "Nobody" <nob***@nobody.com> wrote: He thank you> The windows API supports a mode of ListView called virtual ListView control, > the VB6 control doesn't utilize it. Basically, it's the same as a regular > ListView, but the data is not stored in the ListView, only the displayed > information, so it's much faster. Here is a VB6 sample: > > http://www.mvps.org/vbvision/Sample_Projects.htm#Virtual_ListView_Demo > > Make sure that you are looking at "Virtual ListView Demo.zip (19KB)", not > "Virtual Listbox Demo.zip (34KB)". When you download the sample, it has a > debugging library reference missing. You can download it(the link is in the > sample description), but you should not use it in the released version. You > have to go to Project properties, Make tab, at the bottom, under > "Conditional Compilation Arguments", set DEBUGWINDOWPROC to 0. When you set > it to 0, you don't need the debugging library, but without it, the IDE might > crash if there is a run time error in the windows procedure. I am going to use it in my projects. Will it keep working in .NET as well? Have a nice weekend Catharinus van der Werf csvanderw***@planet.nl "catharinus" <csvanderw***@planet.nl> wrote in message Nothing you do in VB6 will work in .Net. .Net is not backward compatible.news:eb2f88e2-5320-42f7-baf1-3b0cd3622395@r3g2000vbp.googlegroups.com... > Will it keep working in .NET as well? http://msdn.microsoft.com/en-us/library/skw8dhdd.aspx On 16 mei, 16:12, "Nobody" <nob***@nobody.com> wrote: Oke,> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:eb2f88e2-5320-42f7-baf1-3b0cd3622395@r3g2000vbp.googlegroups.com... > > > Will it keep working in .NET as well? > > Nothing you do in VB6 will work in .Net. .Net is not backward compatible. > > http://msdn.microsoft.com/en-us/library/skw8dhdd.aspx still a question,. Is it possible to sort columns and not only the first I want to use the arrow-gright and arrow-left to move from left to right and vice versa, So move from column 1 to the last column and vice versa. And I want the selected column to be sorted alfabe4tically or sequentially. Is that alslo possible with this listview? Thanks Catharinus van der Werf csvandew***@planet.nl "Nobody" <nob***@nobody.com> wrote in message Made a typo above, the default CacheSize property is 1, not 10.news:u6B9mnX1JHA.3476@TK2MSFTNGP05.phx.gbl... > CacheSize property affects this, allowing you to move backward few > rows(the default is 10 rows), but then you get errors after moving back 11 > rows. "catharinus" <csvanderw***@planet.nl> wrote in message Populating the grid using a loop is slower than using "Set". Here is a news:927b121b-dd18-4dd3-a8bb-a8d5fe5665cb@v17g2000vbb.googlegroups.com... > do while not mrstRecordSet.EOF > > me.text1(0).text=mrstRecordSet.fields(0).value > mrstRecordSet.movenext > loop revised sample using MSHFlexGrid: Option Explicit Dim con As ADODB.Connection Dim rs As ADODB.Recordset Private Sub Command1_Click() Dim ConStr As String Dim sql As String Dim t As Single Const sDBFileName As String = "C:\Test\NWIND2000.MDB" ConStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & sDBFileName Set con = New ADODB.Connection con.CursorLocation = adUseServer con.Open ConStr Set rs = New ADODB.Recordset sql = "SELECT * FROM [Order Details]" Debug.Print "sql = " & sql t = Timer rs.Open sql, con, adOpenKeyset, adLockOptimistic Debug.Print "Time taken: " & Timer - t Debug.Print "RecordCount = " & rs.RecordCount Debug.Print "CursorType = " & rs.CursorType Debug.Print "Supports(adBookmark) = " & rs.Supports(adBookmark) t = Timer Set MSHFlexGrid1.Recordset = rs Debug.Print "Time taken by MSHFlexGrid: " & Timer - t End Sub Private Sub Form_Unload(Cancel As Integer) ' Clean up Set MSHFlexGrid1.Recordset = Nothing If Not rs Is Nothing Then rs.Close Set rs = Nothing End If If Not con Is Nothing Then con.Close Set con = Nothing End If End Sub Output: sql = SELECT * FROM [Order Details] Time taken: 0 RecordCount = 2155 CursorType = 1 Supports(adBookmark) = True Time taken by MSHFlexGrid: 0 System: XP Pro+SP2, 4GB, 2.4 GHz Intel Quad processor There is a flag in MSHflexGrid, (repaint ?) that you can set to false when
you load the data, and set it to tru when you are done. It might speed things up. Show quoteHide quote "catharinus" <csvanderw***@planet.nl> wrote in message news:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... > Hello > > I have build a windows-copy of a DOS-accounting program. > All works nice, but the only thing that bothers me is the fact > that loading a large number of records is not as quick as in DOS. > How can I solve that problem. The data are shown in a MSHFlexGrid and > comes from an Access-database. > > The diference between the DOS-and Windows program is probarbly caused > by using a different technic. It looks as DOS reads all the time from > and to the hard disk (and thus has only the visible records /data in > the memory) as Windows first loads all the records and so has all > these records all the time in memory. > > Am I right and is there a solution for the delaying loading in the > windows- > program? > Thanks > Catharinus van der Werf > csvanderw***@planet.nl
Show quote
Hide quote
On 15 mei, 15:03, "Phil H" <phung1***@hotmail.com> wrote: Oke Phil> There is a flag in MSHflexGrid, (repaint ?) that you can set to false when > you load the data, and set it to tru when you are done. It might speed > things up. > > "catharinus" <csvanderw***@planet.nl> wrote in message > > news:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... > > > > > Hello > > > I have build a windows-copy of a DOS-accounting program. > > All works nice, but the only thing that bothers me is the fact > > that loading a large number of records is not as quick as in DOS. > > How can I solve that problem. The data are shown in a MSHFlexGrid and > > comes from an Access-database. > > > The diference between the DOS-and Windows program is probarbly caused > > by using a different technic. It looks as DOS reads all the time from > > and to the hard disk (and thus has only the visible records /data in > > the memory) as Windows first loads all the records and so has all > > these records all the time in memory. > > > Am I right and is there a solution for the delaying loading in the > > windows- > > program? > > Thanks > > Catharinus van der Werf > > csvanderw***@planet.nl- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - I think you mean 'Redraw' I remember and i helps, but not enough Catharinus
Show quote
Hide quote
"catharinus" <csvanderw***@planet.nl> wrote in message Ignoring for the moment your assumption of the difference in File I/O, thenews:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... > Hello > > I have build a windows-copy of a DOS-accounting program. > All works nice, but the only thing that bothers me is the fact > that loading a large number of records is not as quick as in DOS. > How can I solve that problem. The data are shown in a MSHFlexGrid and > comes from an Access-database. > > The diference between the DOS-and Windows program is probarbly caused > by using a different technic. It looks as DOS reads all the time from > and to the hard disk (and thus has only the visible records /data in > the memory) as Windows first loads all the records and so has all > these records all the time in memory. > > Am I right and is there a solution for the delaying loading in the > windows- > program? answer is no, as one can make the case that in general a desktop Windows application will be slower than its DOS counterpart. But you are really comparing Apples and Oranges. A DOS application has some advantages - the most important and obvious one is that it has the complete attention of the hardware - there is always a more "direct" route or fewer layers of stuff between here and there. This is true of honoring disk requests and of displaying data. So it isn't just the File I/O that will be slightly faster (and not because of "delay") but also the presentation - writing to a screen buffer with character I/O is faster than submitting data to a window'd control. However, Windows also has many advantages. Everything is a trade-off. But with that said, it doesn't necessarily mean a Window application has to be horribly slower than its DOS counterpart. It means we often need to change the way we architect/design the program. In many cases a DOS to Windows conversion can actually produce an application that provides the illusion of being just as fast or faster than its DOS counterpart. In your case - do you actually need all those rows at one time? Are you fetching more fields than you need? How is your database design? How are you 'loading' that Grid? Do you have to have that huge grid? Can you rework the presentation, perhaps spreading the "load" to other faster controls? What data access library are you using? For a desktop application using VB6 and a local Jet database the fastest solution is to use DAO. -ralph
Show quote
Hide quote
On 15 mei, 15:12, "Ralph" <nt_consultin***@yahoo.com> wrote: Thank you Ralph> "catharinus" <csvanderw***@planet.nl> wrote in message > > news:3f8a6703-6f51-450d-96ac-397caa442bd4@n8g2000vbb.googlegroups.com... > > > > > > > Hello > > > I have build a windows-copy of a DOS-accounting program. > > All works nice, but the only thing that bothers me is the fact > > that loading a large number of records is not as quick as in DOS. > > How can I solve that problem. The data are shown in a MSHFlexGrid and > > comes from an Access-database. > > > The diference between the DOS-and Windows program is probarbly caused > > by using a different technic. It looks as DOS reads all the time from > > and to the hard disk (and thus has only the visible records /data in > > the memory) as Windows first loads all the records and so has all > > these records all the time in memory. > > > Am I right and is there a solution for the delaying loading in the > > windows- > > program? > > Ignoring for the moment your assumption of the difference in File I/O, the > answer is no, as one can make the case that in general a desktop Windows > application will be slower than its DOS counterpart. > > But you are really comparing Apples and Oranges. A DOS application has some > advantages - the most important and obvious one is that it has the complete > attention of the hardware - there is always a more "direct" route or fewer > layers of stuff between here and there. This is true of honoring disk > requests and of displaying data. So it isn't just the File I/O that will be > slightly faster (and not because of "delay") but also the presentation - > writing to a screen buffer with character I/O is faster than submitting data > to a window'd control. > > However, Windows also has many advantages. Everything is a trade-off. > > But with that said, it doesn't necessarily mean a Window application has to > be horribly slower than its DOS counterpart. It means we often need to > change the way we architect/design the program. In many cases a DOS to > Windows conversion can actually produce an application that provides the > illusion of being just as fast or faster than its DOS counterpart. > > In your case - do you actually need all those rows at one time? > Are you fetching more fields than you need? > How is your database design? > How are you 'loading' that Grid? > Do you have to have that huge grid? > Can you rework the presentation, perhaps spreading the "load" to other > faster controls? > What data access library are you using? > > For a desktop application using VB6 and a local Jet database the fastest > solution is to use DAO. > > -ralph- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - I was only trying to find an easy way to solve the problem, but there i'sn't as I read your comment. I just have to change the architecture and that is ashame. I htis point I am disappointed in Windows and there solutions in reading data. In fact, there is not an easy way of reading a very big amount of data in a simple way like the DOS-account program I mentioned does. It is time that some creates an easy way, maybe I wil try. Catharinus van der Werf csvanderw***@planet.nl "catharinus" <csvanderw***@planet.nl> wrote in message Are you committed to using Jet? There are other "database options".news:1d7cb74e-dcc5-4e84-86f1-d4f858cb418e@o30g2000vbc.googlegroups.com... > > I was only trying to find an easy way to solve the problem, but there > i'sn't as I read your comment. I just have to change the architecture > and that is ashame. I htis point I am disappointed in Windows and > there solutions in reading data. In fact, there is not an easy way of > reading a very big amount of data in a simple way like the DOS-account > program I mentioned does. It is time that some creates an easy way, > maybe I wil try. For example, CodeBase (a library wrapper for xBase) can sort a million records in less than a second. Most accounting applications (with a few glaring exceptions) use a custom database, with a custom access library. I noticed you said you were using ADO. Unless your database is remote use DAO. -ralph "catharinus" <csvanderw***@planet.nl> wrote in message Not true, certainly if you load a file line by line or record by record then news:1d7cb74e-dcc5-4e84-86f1-d4f858cb418e@o30g2000vbc.googlegroups.com... > In fact, there is not an easy way of > reading a very big amount of data in a simple way like the DOS-account > program I mentioned does. > Catharinus van der Werf > csvanderw***@planet.nl it is slow, but no programmer beyond neophyte would even consider loading a large file in that manner, you set a buffer to the file size or if really huge a large chunk of the file then you use GET to fill that buffer in a single operation. With the file in memory it's now easy and fast to split into lines or records. You can also use PUT to write the whole file or large chunks in a single operation. These are native to VB6, there are API file operations that should be even faster but unless you really need every last millisecond Get & Put should suffice. Example: Dim Buff as String Dim ff as integer ff = FreeFile Open "SomeFile.Txt" For Binary As ff Buff = Space(LOF(ff)) Get ff,,Buff Close ff Dave O. "catharinus" <csvanderw***@planet.nl> schrieb im Newsbeitrag The "easy way" is, to use the builtin DataBinding-Features ofnews:1d7cb74e-dcc5-4e84-86f1-d4f858cb418e@o30g2000vbc.googlegroups.com... > I was only trying to find an easy way to solve the problem, a certain Grid-Control, meaning - the Grids usually have builtin methods, to fill their internal "Data-Rendering-structures" more efficiently, if you pass the Container (the ADO-Recordset) directly to them ... and that in only one line of code! e.g. Set HFlex.DataSource = Rs or... Set VBDataGrid.DataSource = Rs The latter one (the VB-DataGrid-Ctl) is the faster one in this case, since it does not make an internal copy of the data, which are already there in the Rs (and it only renders its currently visible lines, depending on the current Scroll-Pos - directly from the Rs-Container). So in case of the VB-DataGrid-Control the over-all-timings you can achieve, mainly depend only on the time until your Select-Call returns with the (properly filled) ADO-Rs. So please stop that out first - how long it takes to retrieve a completely filled-up ADO-Recordset from your DB. Please use clientside-cursors for that task (meaning: Cnn.Cursorlocation = adUseClient). The time, to set the VB6-DataGrids DataSource to your Rs (implicitely rendering only your first visible Records from the Rs) is nearly negligible - and takes usually only 1-3msec, depending more or less only on the internal Field-Count of the Rs (depending on what you've specified in your Select). > but there i'sn't as I read your comment. As just told, you are using your tools probably not inthe right way - e.g. the time to retrieve an ADO-Rs from the "ubiquitous" NWind.mdb - for example 2155 Records and 5 Columns ("Select * From [Order Details]") takes only ca. 50msec here on the first run - (on not yet cached table-data) and on the second run only ca. 7msec. This is the timing for only the plain Rs-Select (containing all the records already after returning) - now add the 1-3msec (for setting the Grids DataSource) on top of that - and you will get ca. 52msec total in case of the first run - and ca. 9msec only in case of repeated runs. So rendering (visualizing in a Grid) is in now way a timing- problem nowadays (in case the Grid plays well with the already existent Rs-Data). So, you can reduce your problem to the time it takes, to completely fill up your ADO-Rs from your DB. And (as you wrote) when your Select only retrieves ca. 3000 records (doing a normal Table-Scan with only a simple Order By), then you should expect "fill-up-times" for an (clientside Cursor) ADO-Rs of ca. 75-150msec on the first run (uncached scan) and ca. 15-30msec on a second run (working against cached data) - depending only somewhat on your Column-Size. And these maximum-times of ca. 150msec (for selecting ca. 3000 records against properly indexed DB-tables) is in no way something I would consider "a user-visible" timeout ... And regarding DOS->Windows. Of course there are a few more layers you will have to go through compared with DOS (not to mention the multitasking of the newer OSes) - but the IO-layers of the new OSes are usually tuned in a great way - also making use of DMA and all the new stuff available on the modern IDE/SATA subsystems and drivers, which should outperform any "DOS-Box" out there, if we talk about IO-throughput and modern cache- strategies on top of that. So, please tell us your timings for your plain select (and do switch-on the adUseClient on your JET-connection). Don't do any looping over your retrieved Rs so far - just tell us the time you need for a plain Rs.Open "Select ...", ... Olaf Catharinus,
It is answered already by Phil, but do you have the piece of code where you load the MSFlexgrid in the Dos program. However, as it is about reading: There is no need to read more then is needed by using the right "where" clause for the SQL part of your recordset. Cor |
|||||||||||||||||||||||
Other interesting topics