WIN 7: What gigherz and hardware issues could be dragging my ACCESS data entry speed

[rogeye]

I have used a a table with (2) one-to-many relationships and (3) one-to one relationships to other tables for years to manage client data. On the Dell XPS15 2.8 gHZ 8 RAM i7 quad core 1 Terabyte SSD machine RUNNING WINDOWS 7 (with 30 Chrome tabs open, 4 excel spreadsheets open, idrive running, 6 word documents open, and not restarting the laptop for days on end, I can input data field to field and select other records from my combobox, and jump to menu items and other tables and queries very fast....almost speed of electricity. 25,000 records / 54 KB of hard storage (compact & repair on close, maybe once every 10 days)



THE PROBLEM:

When I use the same database "data management system" on any of three XPS12 machine 2.0 GHZ 8 RAM i7 quad core 512GB SSD WINDOWS 7 the field to field response is bad. On two machines, I literally just bought a brand new 512K SSD and installed WIN7 fresh and nothing else at all is on the machine, the response time is slightly better but still 1.5 to 2 seconds every time I move to another field. I can't live with that. I move to another field and am still waiting for the cursor to catch up. Even drop down selections don't automatically highlight for half a second.

I am considering buying a FRAMEWORK 32GB RAM 4.8 Ghz 1 TB SSD machine, but am afraid there will be some sort of incompatability with hardware and my WIN 7/ACCESS "system". What could be slowing the response time (is it i/o?) and what can I do? How can I be sure ACCESS 2007 and WIN 7 will run right on the FRAMEWORK or a brand new up to date DELL?

I am an amateur programmer. I understand a lot but I am not of professional sophistication

[Minty]

Where is the data (backend) stored, and how are you connected to it?

[rogeye]

Where is the data (backend) stored, and how are you connected to it?

I have two applications. this database is not split. there is no backend. remember, it works fine on one machine but not the other. I am trying to
focus on what is different between the two operating environments.

I woke up thinking today, that on the XPS12, whether I am in WIN 10 or WIN 7, when I click on the .mdb and when it opens in the XPS12, I get a security Warning: Certain content in the database has been disabled. I click OPTIONS: Security alert "VBA MACRO" . In order to see any data or input new data and change data in the fields, I have to "Enable the content". I don't get that prompt on the XPS 15 machine. How can that be? Could a security Macro or background program be stopping every I/O transaction and checking it. That is what is slowing it down?

There is a Trust Center with Macro settings

I hope someone can shed light on the previous observation, and I hope it is relevant, so that I can avoid the next observation and action I just took.
I compacted and repaired manually and then closed the DB so it would immediately repair by automatic setting (it always is on automatic).
When I reopened, it was maybe 5% faster. Still way unacceptable. So I deleted half the records. Instead of 25, 000 there are now 9721.
As a result, it is about 90% as fast as my XPS15. record #1 is again about 95% as fast as record # 9721, if I can even judge the difference.. Certainly "livable"

So what does that mean? What is slowing down the application due to record quantity on one machine and not the other. Do I really have to delete old records. and jump back and forth between two applications, if I need an old record once in a long while?

This application cannot be split. Long story. Let's not get into Table and relational design issues. 15 years ago I decided to live with a flat design fo r so called user operational reasons and now I have to live in the bed I made. I have no time to redesign and export data and reload.. On the one hand my application is large, intricate, complex, and impressive. On the other hand it is amateur and somewhat inefficient. That is not the issue here. The system is GREAT on the XPS15/WIN 7. The issue is how can moving the application to a 2.0 GHz system cause a security warning and run unacceptably slower with over 12,000 records

So back to the issue, how can I avoid deleting all these records? what is going on mechanically?

I thought if I used WIN 7 instead of WIN 10 to handle the I/O with ACCESS 2007 that would solve the problem. Maybe WIN 10 was not the issue.
I just test ACCESS 2007 in WIN7 on the XPS12 and found that by deleting 40% of the the records and leaving 14,000 records and compacting and repairing (instead of 25,000) the database is 97% speed of the XPS15

So why is record count an issue on the 2.0 ghz machine? even if there is no other software on the machine. no third party background applicaitons ?other than idrive?

[CJ_London]

What is slowing down the application due to record quantity on one machine and not the other.

this comment implies your tables are not indexed - at least not in a way that impacts performance. Pretty much confirmed with this comment

I just test ACCESS 2007 in WIN7 on the XPS12 and found that by deleting 40% of the the records and leaving 14,000 records and compacting and repairing (instead of 25,000)

The issue is how can moving the application to a 2.0 GHz system cause a security warning

implies the file is a .accdb and not in a trusted location

And although you want to ignore table design et al, if your design does not meet standard database requirements, expect inefficiencies which will become more apparent with larger datasets

[rogeye]

this comment implies your tables are not indexed - at least not in a way that impacts performance. Pretty much confirmed with this comment

implies the file is a .accdb and not in a trusted location

WRONG!!! If you bother to even read all the info I offered, the file is .mdb, so plz keep your useless comments to yourself if you are too stuck up to bother reading, know it all

And although you want to ignore table design et al, if your design does not meet standard database requirements, expect inefficiencies which will become more apparent with larger datasets

WRONG again AJAX!!!! the table is indexed. That comment is beside the point. If you bothered to think, the "system" should run the same way no matter the machine, if the OS is the same and nothing else is on the SSD. So stop commenting when others who are more interested could reply.

I don't appreciate you throwing up garbage and preventing others who have real insight from seeing a post gone un-replied to

[CJ_London]

Your abusive comments won’t earn you any brownie points. So I’ll leave it to others to see if they want to risk incurring your sarcasm

[Minty]

I have two applications. this database is not split. there is no backend. remember, it works fine on one machine but not the other.

You don't need to remind me of the machine differences, but until you told us we had no clue your database was a stand alone unsplit system.

Your attitude to Ajax won't win you any friends. He was making valid suggestions, just because you don't want to listen to them you don't need to be rude.
Your own experiments would indicate that record numbers and therefore inefficient indexing or design is an issue, if you won't or can't change it you are now reaping your reward for a poor design.

Are you dragging every record into your forms (it sounds like it), rather than an empty form to then find the records you need?

If you are working in tables directly this can be slow (based on the items below), however on a purely local database it should be pretty quick.
Do you have lookup fields in your tables - don't.
Do you have subdatsheets switched on they can really slow things down.

[rogeye]

[QUOTE=Minty;480779]

This is the problem with community forums serviced by so-called VIP. I have experienced this before. VIPs don't really read. They go back to their same old stuck up knowledge and shove it down community throats.

All of your comments are so utterly irrelevant. Plainly obvious, because you do not bother to empathize.

I clearly said my complex application works like greased lightning on all 25,000 records, on XPS 15 2.8 ghz machine. So all your BS comments about
table entry, and record dragging, and table lookups , and all your stuck up progam efficiency notions are irrelevant. My GUI and design work wonderful on the one machine.

So if you won't bother to try to be intelligent and use actual brain cells to think out of the box, stop responding to my thread PLEASE.
You bring the sarcasm on yourself, because you are lazy. You want to throw some one liner crap at us to expend the least energy and tick off a "service call"

No one with real thinking skills and an understanding of hardware is going to respond, if you keep racking up the replies. Get off my thread. Let someone who "Gets it", respond

The issue is changing hardware.

Something is triggering a Security Alert and an I/O issue.

Minty suggested TRUSTED LOCATION. I did add the folder to TRUSTED LOCATION and that got rid of the security alert. But the I/O did not improve
I suppose years ago I must have identified the XPS15 folder as TRUSTED and do not recall doing that now. That is the only explanation for that.

ButI am still stuck with my mystery. Why does the GUI and db work so poorly on a different i/7 core SSD supported system , the only aparent hardare difference is the gigaherz reduction.

Does that mean 2.0 ghz is not enough? and 4.0 will be twice as fast?

[CJ_London]

This is a software forum so suggest go find a hardware forum or go get paid advice since you have such a low opinion of free advice.

Think I understand you have moved from a fast device to a slower device and your app runs slower and you don’t understand why. I feel your pain but your attitude stinks so good luck

[Minty]

Wow you really are special.

Your application is so brilliant that nothing can possibly be wrong with it's design, but it only works to your satisfaction on one machine.
So it must be the hardware. Obviously.

Welcome to the ignore list.

[kd2017]

So fascinating that people like this exist in the world. It's interesting to encounter one in the wild (from a safe distance)!

[rogeye]

but it only works to your satisfaction on one machine.

A sign of life.

So you finally get that the application runs great on a 2.8 ghz.

The question is whether ACCESS bogs down and is a dog on a 2.0 ghz machine.
The question is do experienced programmers already know that a 40% reduction in gHz would have a significant effect on I/O?
It is obvious that Minty, Ajax, and kd2017 have no real knowledge of hardware, so please stay off my thread. It is really very
unprofessional, if unkind, to continue to harangue my thread when they having nothing intellectual to contribute.

Is there anyone else out there that can take for an assumption that any application, regardless of its efficiency in design and mild intentional redundancy, would by definition have significant reduction in I/O, GUI to database, by reducing Ghz? or is there some other hardware issue to consider
when moving from one i/7 quad core machine to another model ? is 40% reduction in Ghz considered significant for an application handling only 25, 000 records? What technically would explain why an 8 year old i/7 with 8 RAM be able to run a faulty designed application with great I/O response, but other machines of similar era-technology and RAM have significantly poorer performance.

Thoughtful respondents only please.

[CJ_London]

The question is do experienced programmers already know that a 40% reduction in gHz would have a significant effect on I/O?

as an experienced programmer - yes if the app is not efficient. Same goes for a network which is 40% slower than another or using a disc hard drive rather than SSD - if the app is not built to run efficiently. An efficient app might lose a few percent, but not 40%. And before you rant - I know you are only running a small unsplit db on your local SSD drive. There is someone on this and other forums who has done numerous performance tests on different equipment and different app processes to demonstrate this. I would provide links, but given your attitude, you can do the searching for yourself.

It is standard practice to build to the minimum spec - be it drive, network, monitor size, access version, whatever.

I am not of professional sophistication

totally agree