Speeding up programs

[pramod2179]

Hi

How does one speed up programs in VB6 Access 2K combination? The mdb size can go upto 200 MB. I have an invoicing module and 150 invoices are generated every day. I am starting with "insert" in place of "add new" for new records. Queries instead of "update" during editing. Suggestions are welcome.

Pramod

 

[bluenote]

in pure vb code i recomend to replace all string manipulation functions, such as right, left, str, mid , etc .. for right$, left$, str$ mid$, lcase$, ucase$, etc ...

inside functions use a var that store the length or a string, dont use Len(myString) over and over in the same function ..... i shure you that this kind of things will speed up your code ...


hope it helps ....: bluenote@uyuyuy.com
(excuse my english)

 

[fluteplr]

Get rid of access, and use a real database such as SQL server or even MSDE (Microsoft Data Engine)/

 

[jfrost10]

Hey Pramod,

One thing that our company found helped speed things up was to compact the database regularly.

With Access, if you delete a record, the row still exists and takes up space (kinda like in Quake where even though you may blow a guy away, his body still stays lying around? Bad analogy, but only thing I could think of this early )

Access has its own compacting function that will go through and get rid of all these empty rows that just sit there, and we've found that a fairly huge database can actualy be reduced by anywhere from 1/2 to a 1/4 of its size!

Worth taking a look into anyway.

Laterz,
Jack

 

[MichaelRed]

One usual source of timming problems in any large db is the net work. 90%+ of all networks are set up (e.g. default 'optimization') is for the generic 'office' pool. Letters, memos, spreadsheets, e-mail, presentations ... while database systems often NEED different settings in critical areas. Talk to the 'Net Cop' on your beat had see if/what they know about this. If it "DUH", you are in real trouble. If it is the proverbial "light bulb going off" expression, help may be forthcomming. It is probably somewhere in between, and you will need to be 'agressive' in persuit of (their) understanding.

Another real problem is the location of the db part with respect to the gereric network stuuuuffffff. If the db access is in contention with "the universe", it can have aa huge impact. If - for example - the db is on the same 'server' as a shared internet connection, then every web page loaded on every worstation is contending with your db for processor time. All dbs SHOULD be seperated from the general 'office' apps. Ideally, the dbs and their users should be on a seperate NETWORK from the generic office apps.

MichaelRed
mred@att.net

There is never time to do it right but there is always time to do it over