Why is Access 97 so much faster than VB6 when searching?
in [Visual Basic]
|
From: Schmidt on 6 May 2010 16:26 "Schmidt" <sss(a)online.de> schrieb im Newsbeitrag news:uo4wXmV7KHA.1888(a)TK2MSFTNGP05.phx.gbl... Arggh, sorry - hit the send-button on mistake. Just wanted to add an "encouragement", to just ask, if something is not clear regarding the usage of the wrapper - oh, and please download the already mentioned Demo-package (containing the NWind-Demo), to look after appropriate code- snippets on how to accomplish different things. Olaf
From: Schmidt on 6 May 2010 16:39 "GS" <GS(a)discussions.microsoft.com> schrieb im Newsbeitrag news:edSH6$N7KHA.5476(a)TK2MSFTNGP06.phx.gbl... > I downloaded your Richclient to learn how to use it for reg free > loading. I saw the SQLite part and overlooked it because I mostly use > text files or Excel spreadsheets for storing data. After reading this > thread I feel that this part will be most useful as a replacement for > how I store data now. My problem is that I don't know much about DB > programming beyond using ADO in the above mentioned context. If you know ADO, then you should be able to use the SQLite-Recordsets too without larger problems. Useful for Excel-Cell-Interaction (to fill-up larger Cell- Contents) are the Rs.GetRows - and Rs.GetRowsWithHeaders methods of the cRecordset-Class. Both will deliver a Variant-Array, which can be "placed" within a selected Sheet-Range with one single (VBA-) line of code. And since Excel also supports, to fill up a Cell-Range directly from an ADO-Rs with a single call, you can provide this Excel-VBA-function with an ADO-Rs this way (assuming 'Rs' is an SQLite-Recordset): Range.CopyFromRecordset Rs.GetADORsFromContent or somewhat more directly per: Range.CopyFromRecordset Rs.DataSource Also useful in XL-scenarios is the ability of SQLite to create InMemory-Databases "on the fly" and with ease - you can then use the power of SQL-queries, to filter, sort and/or group your Data-content, which you uploaded beforehand into the InMemory-Tables. > Now that you have sparked my interest in your wrapper, are you > available after this NG goes bye-bye for Qs I may have about using > RichClient? Of course, just let's find a new place - hopefully one, which *everybody* is willing to accept as the "new home". > P.S.: I don't want to add any influence to your answer to my request, > but while we're still here I'd just like you to know how thankful I am > for your many contributions in this NG which added to my VB learning > process. I really appreciate it! Thank you... :-) Olaf
From: GS on 7 May 2010 03:50 Schmidt formulated the question : > "GS" <GS(a)discussions.microsoft.com> schrieb im Newsbeitrag > news:edSH6$N7KHA.5476(a)TK2MSFTNGP06.phx.gbl... > >> I downloaded your Richclient to learn how to use it for reg free >> loading. I saw the SQLite part and overlooked it because I mostly use >> text files or Excel spreadsheets for storing data. After reading this >> thread I feel that this part will be most useful as a replacement for >> how I store data now. My problem is that I don't know much about DB >> programming beyond using ADO in the above mentioned context. > > If you know ADO, then you should be able to use the > SQLite-Recordsets too without larger problems. > > Useful for Excel-Cell-Interaction (to fill-up larger Cell- > Contents) are the Rs.GetRows - and Rs.GetRowsWithHeaders > methods of the cRecordset-Class. > Both will deliver a Variant-Array, which can be "placed" > within a selected Sheet-Range with one single (VBA-) line > of code. > > And since Excel also supports, to fill up a Cell-Range > directly from an ADO-Rs with a single call, you can > provide this Excel-VBA-function with an ADO-Rs > this way (assuming 'Rs' is an SQLite-Recordset): > Range.CopyFromRecordset Rs.GetADORsFromContent > or somewhat more directly per: > Range.CopyFromRecordset Rs.DataSource > > Also useful in XL-scenarios is the ability of SQLite > to create InMemory-Databases "on the fly" and with > ease - you can then use the power of SQL-queries, > to filter, sort and/or group your Data-content, which you > uploaded beforehand into the InMemory-Tables. > The InMemory-Databases concept sounds really cool, so I'll be sure to investigate that. I already have wrappers for working with ADO, both on Excel files and text files. I guess you could say I already create Inmemory-Databases when I load the data into a rsVar. I usually work on it there before updating the file source. Of course, this is easy when it's always a single user but I need to evolve that for multiple users and network use. What I was meaning to convey is I'm thinking to move away from storing data in text files or spreadsheets due to the associated lack of security. I'm thinking that if SQLite DBs have access security features that are reasonable, they would be a good alternative to using MDBs, for example. > >> Now that you have sparked my interest in your wrapper, are you >> available after this NG goes bye-bye for Qs I may have about using >> RichClient? > Of course, just let's find a new place - hopefully one, which > *everybody* is willing to accept as the "new home". > >> P.S.: I don't want to add any influence to your answer to my request, >> but while we're still here I'd just like you to know how thankful I am >> for your many contributions in this NG which added to my VB learning >> process. I really appreciate it! > Thank you... :-) > > Olaf Off topic Q: Will CommonCOM.dll also work for using OCXs reg-free? Garry
From: Schmidt on 7 May 2010 06:34 "GS" <GS(a)discussions.microsoft.com> schrieb im Newsbeitrag news:%23E%23RFob7KHA.5476(a)TK2MSFTNGP06.phx.gbl... > What I was meaning to convey is I'm thinking to move away > from storing data in text files or spreadsheets due to the > associated lack of security. I'm thinking that if SQLite DBs > have access security features that are reasonable, they would > be a good alternative to using MDBs, for example. You can encrypt an entire SQLite-Database over the wrapper (once you opened a DB-connection successfully) per: Cnn.ReKey "YourEncryptionKey" followed by closing the Connection per: Set Cnn = Nothing 'there's no Close-Methods as in ADO And then for reopening the now encrypted DB-File, you will need to provide the Key in an optional Parameter: Set Cnn = New cConnection Cnn.OpenDB DBFileName, "YourEncryptionKey" After a successful opening as shown above, you can work in a similar way with the Cnn - the Data is automatically decrypted and encrypted (the latter in case of the write-direction into the DB). One will lose only about 10-15% of performance whilst working with these encrypted DB-Pages. > Off topic Q: > Will CommonCOM.dll also work for using OCXs reg-free? DirectCOM.dll only supports the regfree loading of ActiveX-Dlls. I've had support for regfree OCX-loading built into the older dhRichClient.dll (note the missing '3'), but that mode was working reliable only for VB6-compiled OCXes - not each and every (C++/ATL) compiled 3rd-party OCX out there was behaving correctly in this mode, so I removed the feature in the 3er series of the RichClient - also already having the new Widget- Controls in mind, which can be hosted in plain VB5/6 ActiveX-Dlls - and these are regfree loadable again per DirectCOM.dll. These "new Widgets" are something like "Vaporware" in the meantime, since I mention them as "ready soon" now since over a year... <g> But I hope, that my next announcements on the list, will restore "some faith" again, since I'm now on a good way "down the road", to accomplish the final goal, to offer a capable and easy to use Vector-based Drawing- and Widget-Engine for the VBClassic-community (and myself too of course ;-). Olaf
From: GS on 7 May 2010 14:56
Thanks so much for these details. My reason for asking was that some clients want to be able to carry my apps around on a USB drive so they're 'portable' for use on any machine. This currently requires reg of ActiveX components on startup, then unreg on shutdown. Sure would be nice to not have to do that since some systems may prevent doing that. So far it hasn't been an issue but I'm sure some corporate Group Policy will eventually make it one. Garry |