Page 2 of 2 FirstFirst 12
Results 16 to 20 of 20
  1. #16
    Join Date
    Jun 2010
    Location
    Belgium
    Posts
    1,035
    Hi Rogeye,

    on this forum there are a lot of professionals that freely give their time to help you. Instead of going on that you're right please try out their suggestions, they make sense. And yes, we all have payed jobs along this forum and not always the time to go into every detail. If you want to do it your way, there's no point in asking advise, is there?

    Regarding the size of your database: indexes are kept as separate tables, so they do increase the size. So does regular inserting and deleting of a lot of data. I's not because you have deleted the data the Access file will get smaller directly. You need to compact and repair to do this.



    I think Davegri has a lot of patience and given some solid advise.

  2. #17
    rogeye is offline Advanced Beginner
    Windows 7 64bit Access 2007
    Join Date
    Nov 2017
    Posts
    36
    I want to thank you for entertaining my quandry and posts. I find the entire ARCHIVE, SET,


    APPEND, and programming issue daunting and have put it off until tonight. I started re-


    reading your great suggestions and felt the wieght of the challenge to understand your


    suggestions again. So I kept asking the question to myself, "There has to be something


    fundamentally different about the platform. The answer lies there, not in ARCHIVING. Why?


    Because the application runs fine on WIN 7 XPS15 8 RAM. The application is only 55 KB. The


    XPS12 is an equivalent device. THINK MAN, THINK!


    I noticed that my main table primary key looks different in design view on the XPS12.


    On the XPS15 WIN 7 ACC2007, the "ID" field shows INDEX=NO and there is no capacity to toggle


    PRIMARY KEY on or off. Even if I right click the field. The menu selection in DESIGN is


    inactive.


    When I copy over the DB to the XPS12, the "ID" field Wallah! is suddenly INDEX= (YES no


    duplicates) and the primary key icon is toggled on !!


    I thought how strange. I thought, seems like no great consequence, really. The ID field does


    act like a primary key in one to many relationships with the other tables. Those settings are


    fine. But why do they not appear in the original platform? (Do you know why? I would be


    interested)


    So I kept thinking, "There has to be something about the operating environment that is


    messing me up. Then, I came up with the answer.


    For a long time it was bugging me that I always have to ENABLE CONTENT any time I copy the DB


    to the XPS12 and open it. I always get a security warning. I asked guys before, on the


    community site, hardware guys I know, nobody gave it much thought.


    I keep complaining about I/O speed, populating FORM fields from the table.


    Wallah!


    I just figured out the issue.


    Even though I ENABLE the CONTENT, the ACCESS Security must still be surveilling each and


    every I/O !!!!!


    MICROSOFT PIZZA SYmbol
    ACCESS OPTIONs
    TRUST CENTER
    TRUST CENTER SETTINGS
    ADD locations: select C:\USER FILE


    I rushed to try the DB application.


    BANG!! the speed lag is .3 seconds at most, sometimes, down from 2 to 7 seconds per field.
    Some fileds are 100% as fast as the XPS15.


    Lesson: ACCESS Security is relentless.


    Lesson: if your patient tells you it hurts there, then that is where the problem is. Listen


    to your patient.


    I told you guys there is a platform difference issue. The app runs fine in one environment


    for all essential purposes identical to the other. The issue is not record or table size.
    The issue is environmental. The issue is ACCESS SECURITY.


    REMEMBER to TRUST the I/O location.


    I hope you can pass that on to other users at the right time when they ask, in the forum.


    You wer eone of the few who understood I am a dayjobber, joe blow public asking for help and


    looked past my way of speaking. I thank you for that. I hope this information will help you


    and some other poor slob that asks for help and people like "MINTY" and "WELSHgasman, and


    "ISLADOGS" beat them down. These people are so full of themselves and not reallyinterested in


    helping people. They are moreinterested in showing off their B.S. knowledge. And here, me, a


    little ole programming hack, ran a two year circle around them to come up with the easy fix.


    The only fix.


    Kudos: Davegri, Ranman256, NoellaG, Gicu, Vlad Cucinschu


    I really would like to learn about SET, and using TEP tables to create an ARCHIVE FLAG, and


    use append. I hope if I ever find the time to try your suggestions, and those of the


    following people who tried to help me, you will entertain more of my questions. Thanks


    again. And don't forget about the TRUST CENTER.




    Trust me-


    ROGEYE

  3. #18
    rogeye is offline Advanced Beginner
    Windows 7 64bit Access 2007
    Join Date
    Nov 2017
    Posts
    36
    I agree Davegri and yourself have given great advice. I am all for listening. I COMPACT and REPAIR everytime I exit ACCESS. The size is 55KB and noone has commented whether that is so large as to be an outlyer. I doubt it. The fact is, the application and Dbase wizzes along on an i7 Quad core DELL purchased in 2015, dropped and repaired twice. The speed of response issue between platforms (switching to an XPS12 i7 DUAL CORE) requires folks to sit back and think further out of the box. No one has of yet.

    I spent 6 hours today playing with many angles.

    It seems some issues which all eat speed are:

    1) Trust CENTER
    2) New record creation I/O from GUI to table is much slower with a new record than an established record. DoCmd.GoToRecord , , acNewRec
    3) Nesting - my user interface form has at least 8 heavily populated nested subforms. Today, it seems if I eliminate 4 or 5 of the densest subforms, the speed of response [inputting new data and creating a new record) improves significantly. Reducing the number of NESTED subforms has the same impact as TRUSTCENTER or deleting more than half the database
    4) turning the subroutine TIMER() off to stop fields from blinking helped a little, but only a little.
    5) the point is, the hardware matters. A DUAL core i7 8RAM does not process an ACCESS FORM linked to a table with 200 fields (2/3 are completely empty) and 25, 000 records as fast as a Quad core i7 8 RAM . . .. and that is pitiful...but I have to figure out how to work around it..... and if any one is up for a real challenge, it is going to take more than the normal way of approach....even if I remove 100 "empty fields" and delte 10,000 records, and delete 4 nested subforms, the speed of DoCmd.GoToRecord , , acNewRec does not stack up (the 3 to 7 second typing input lag.....is reduced....but a full second lag remains)

    I want to get rid of that last full second lag. I feel like we still do not fully understand what is ACCESS's problem.
    ACCESS 2007 was developed around the peak of DUAL core i5 and i7 sales. ACCESS should be able to handle this. I am using WIN10, but even in I run the application in WIN7 , the performance is identical.

    So what else can you conjure up to look at.

  4. #19
    orange's Avatar
    orange is offline Moderator
    Windows 10 Office 365
    Join Date
    Sep 2009
    Location
    Ottawa, Ontario, Canada; West Palm Beach FL
    Posts
    16,716
    Quote Originally Posted by Danpeterson View Post
    Hello,
    Good decision.
    I would like to suggest you, try Long Path Tool program to resolve this issue. This tool is very helpful to resolve the issue.
    Thanks!

    Dan,
    Does this program have something specific to resolve the OP's issue?
    Do you have some financial or other interest in the Long Path Program?
    Asking about this program seems to be the only response you have to the few responses you have made???

  5. #20
    Join Date
    Jun 2010
    Location
    Belgium
    Posts
    1,035
    Access was never designed for using tables with 200 fields and more. In fact, no database is. Stating that you have linked tables with 200 fields, most of them empty points to a bad database design.
    If you want to speed up the application I would first look at the database design and clean this up. Using nested subforms is another sure way to slow down the application.
    So I would advise to first rethink the database design and then redesign the user interface.

Page 2 of 2 FirstFirst 12
Please reply to this thread with any new information or opinions.

Similar Threads

  1. Replies: 9
    Last Post: 04-16-2021, 01:44 AM
  2. Replies: 2
    Last Post: 06-23-2017, 10:49 AM
  3. Replies: 7
    Last Post: 05-07-2012, 12:00 PM
  4. Risk/Issues Database
    By glassarchitect in forum Database Design
    Replies: 1
    Last Post: 12-01-2010, 09:17 AM
  5. Finding subsequent codes
    By Rixxe in forum Queries
    Replies: 8
    Last Post: 09-15-2010, 02:44 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums