Page 1 of 2 12 LastLast
Results 1 to 15 of 26

Thread: An Idea!!!

  1. #1
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185

    Lightbulb Unanswered: An Idea!!!

    Hi,
    I am workin on an idea which I wanted to share it here and appreciate if you give your opinions.
    I use this configuration when I have a back-end file on share with slow speed (I mean low data transfer) which is loading a copy of data on front-end file in a temp table and speed up the process and make it to be updated with a timer which is depend on how often the data base is being edit by those who have edit permission (for example say each 10 minutes).
    I now maybe most of you think that the whole idea is useless but describing an idea is better than keep it.
    so back to the idea!, I am working on to have a code to see if during last updating data from back-end to front-end temp table period data has changed in back-end or not and if nothing changed then don't update the data.
    I don't want to use checking the data in back-end row by row which it takes much more time and speed than updating the data.
    I'm looking for an index in access tables to say if table is edited or just viewed and...
    Hope everybody give his/her opinion.

  2. #2
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    sorry to rain on your parade
    if you are using Access in a multi user environment then frankly I think its a an approach that sucks, and sucks big time.

    if performance is that much of a problem then you should consider moving to a server back end
    if performance is a problem then you should switch away from bound forms and use unbound recordsets to power your application (argaubly you should do that in any event).
    if performance is a problem then look at your query,form & report design and try to identify bottlenecks
    if performance is a problem then consider buyign a book such as Access Developer Handbooks published by Sybex (get the desktop & enterprise books together), and read those books

    you can copy data locally if you KNOW that it will never change, or if it does any changes are insignificant to the overall app. say you had a product table which was downloaded from the main computer system daily or weekly you could copy that data to a local machine.. but why. I have seen static configuration data loaded to local machines but never volatile or company critical data

    most of the perceived benefits you will get from what you are proposing are offset by the pitfalls, and in any event a well designed application using a server backend will handle all that stuff for you.

    Access as a GUI RAD does a great job for very small db's, it can get a reasonably pretty and usefull application running quite quickly.

    ihowever if you want the prettiness of an Access app in a big multi user site you have to abandon all those dinky little wizards that look so neat, but are ooh so painful with large amounts of data

  3. #3
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    Thanx healdem,
    I'm aware of all those things you mentioned and use most of them, but try to do what I brought up is a challenge, at least for me, I hate doing all those useless things such as animating in forms or jiggly diggly buttons... and as I said it may seems useless but sometimes these useless things give some creative ideas.

  4. #4
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Aran1
    I hate doing all those useless things such as animating in forms or jiggly diggly buttons...
    Wash your mouth out with soap and water! Jiggly diggly buttons and forms flying around all over the place is what differentiates the Soulutioneer from the developer

    Gotta agree with Healdem too - if you really want to spend a lot of time working on the data access speed then consider many things (almost anything in fact) before that.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  5. #5
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Quote Originally Posted by pootle flump
    Soulutioneer
    Oh dear, here he goes again...
    George
    Home | Blog

  6. #6
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    Quote Originally Posted by georgev
    Oh dear, here he goes again...
    but what I find more scary is that he agrees with me, I'm still reeling from the 'Genius' comment a whiles back.

    When management types start agreeing with you that is the time to bail.......

  7. #7
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Jiggly diggly buttons and forms flying around all over the place is what differentiates the Soulutioneer from the developer
    No, this is what makes the difference between wasting the client's money and being efficient
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  8. #8
    Join Date
    Jan 2007
    Location
    UK
    Posts
    11,434
    Provided Answers: 10
    Why did you have to say that!
    Now poots will dig through his archives and find the very debate we had on this subject months ago!
    George
    Home | Blog

  9. #9
    Join Date
    Jul 2004
    Location
    South Dakota
    Posts
    267
    Quote Originally Posted by healdem
    you should switch away from bound forms and use unbound recordsets to power your application (argaubly you should do that in any event).
    Healdem - can you explain to my why you should use unbound forms in a front end / back end configuration? I'm just starting to working on something like that for the first time so I don't want to screw things up. Wouldn't using unbound forms cause record locking issues or at least complicate things trying to avoid that? Thanks.

    C

  10. #10
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by canupus
    Wouldn't using unbound forms cause record locking issues or at least complicate things trying to avoid that? Thanks.
    It actually cuts out most native record locking issues... so you have to produce some sort of concurrency control of your own. Although there are a few variations, the typical thing is to check, before updating a record, that it has not been altered since the operator first retrieved it. If it has - do not save the changes and let the operator know - usually with a "Are you sure you want to do this?" sort of message.

    HTH
    Testimonial:
    pootle flump
    ur codings are working excelent.

  11. #11
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Although I agree that having unbound forms is better, it's a LOT harder to code compared to bound forms. Depends on the size of the application, number of users etc, but it can be preferable to use bound forms imo.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  12. #12
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    For some things it is, for other things it isn't. The big major plus for me is once you have learnt how to use unbound forms you have learnt the principles required for most other front end applications. Plus you only have to write it once - after that it is Copy, Paste, Tweak (assuming you use some nice naming conventions and iterate controls).
    Testimonial:
    pootle flump
    ur codings are working excelent.

  13. #13
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Quote Originally Posted by healdem
    sorry to rain on your parade
    if you are using Access in a multi user environment then frankly I think its a an approach that sucks, and sucks big time.

    if performance is that much of a problem then you should consider moving to a server back end
    if performance is a problem then you should switch away from bound forms and use unbound recordsets to power your application (argaubly you should do that in any event).
    if performance is a problem then look at your query,form & report design and try to identify bottlenecks
    if performance is a problem then consider buyign a book such as Access Developer Handbooks published by Sybex (get the desktop & enterprise books together), and read those books

    you can copy data locally if you KNOW that it will never change, or if it does any changes are insignificant to the overall app. say you had a product table which was downloaded from the main computer system daily or weekly you could copy that data to a local machine.. but why. I have seen static configuration data loaded to local machines but never volatile or company critical data

    most of the perceived benefits you will get from what you are proposing are offset by the pitfalls, and in any event a well designed application using a server backend will handle all that stuff for you.

    Access as a GUI RAD does a great job for very small db's, it can get a reasonably pretty and usefull application running quite quickly.

    ihowever if you want the prettiness of an Access app in a big multi user site you have to abandon all those dinky little wizards that look so neat, but are ooh so painful with large amounts of data

    Good points healdem

    Regarding all the "pretty's" you add to an application - "IF" you're experienced enough to do them and know that you won't be troubleshooting them for the next 10 months to find a problem which ultimately leads back to that piece of code, they do enhance a user's experience with your application (after all, when we play a game or use another application, those little extras keep us ooohing and aaaahing and make using the application fun and richer. But only IF you know how to do it without causing other problems. I personally like to through in a few extras (I had a flying dragon once in the background of one my Access apps - and it looked awesome, worked very well, and only took about an hour to do it.) Otherwise, if you're a beginner, stay away from those goodies which will only cause you headaches for troubelshooting.

    I also used to throw in a game of hangman or dice roll into an application (yes - I had some extra time on my hands) and found that 1-10 users really liked the extra feature. (although 1 out of 10 is not the greatest odds). According to the high-scoring table, I did have about a dozen users who tried it out and kept trying to beat the high score.

    But I have to repeat the first statement - "IF" you're experienced enough to do them....

    Regarding the use of Unbound forms - I use them as the situation predicts (like working on a 3 million recordset db in a multi-user environment.) I wouldn't consider it a necessity if everything is running fine unless the max 3 second rule to return a record becomes 5-10 seconds (other things aside). Then I think it's time to seriously consider going unbound. Unbound is something which aught to be done on all apps, but not required to be done on all apps, but is true client-server type programming and will take any programmer to another higher level of developing applications. Writing unbound forms are in essence, the same philosophys we all were taught in school for programming (you know, remember when we had to write all those routines to write, retrieve, update, and delete a record?) Same philosophy. Access just spoiled us and made it easier to bypass things like that. Now an ADP (or Visual Basic project)....you can't avoid writing those routines.

    For smaller applications, it's a time to finish the project compromise as everyone knows it takes up to 3 times longer writing those unbound forms. But boy, do you get a fast application when it's done (and done correctly.)
    Last edited by pkstormy; 05-02-08 at 00:35.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  14. #14
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    Provided Answers: 59
    I think I have a different view on the pretties in an Access APP, I was referring to poorly thought out use of things like list & combo boxes....

    I had to do some maintenance on an Access front end that was effectively developed in JET and copied straight across onto the server back end.. performance was horrific..... it could take 10..15 minutes for a data entry form to load (because the muppet had designed it using bound controls,, loading a combo box with 8000+ customers each time the form refreshed).. it crippled the network, it crippled productivity, so that form was redesigned to only load customer details after the first 3..5 characters had been typed in and find the closest matches.

    it ended up as 6 months of my life lost clearing out the augean stables. the network trolls hated me, because it meant they didnt get the network upgrade they wanted (so they didn't get lots of fancy new toys to play with)
    I'd rather be riding on the Tiger 800 or the Norton

  15. #15
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    Sorry I wasn't at office for few days, now back to work!!
    Actually I didn't mean to oppose to any body or offense others opinions, I usually use good automation and animating effects in my dbs and I should have said working on these things isn't something new.
    Anyway lets put it in this way, I'm looking to see if there is some kind of index for Access tables to show if the table is altered? If anyone has information I appreciate it.
    Cheers.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •