Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook



The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic

Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.

If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.

Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.

Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Losing records VERY WORRYING

  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Re: Losing records VERY WORRYING

    They only use OpenOffice, and if you open an Alpha DBF file in OO, modify it and save it back, it corrupts some fields across the whole table, so it's obvious it's been tampered with. I thought about it too, so I tried :-) I don't know if Microsoft Office has the same problem, but they don't have Ms Office installed on any computer, and users can't install their own programs.

    I haven't tried to see if you can do this with some of the online office suites - I guess I better try.
    It is easier to get older than wiser


    • #17
      Re: Losing records VERY WORRYING

      I might suggest table encryption for tables that may be having a problem? If someone can open the tables, they would not be able to figureout which record to affect. They would not be able to read them either.

      I understand they cannot install an app, but do the cd's and usb's still work on these computers?


      • #18
        Re: Losing records VERY WORRYING

        Originally posted by amorris View Post
        I might suggest table encryption for tables that may be having a problem? If someone can open the tables, they would not be able to figureout which record to affect. They would not be able to read them either.

        I understand they cannot install an app, but do the cd's and usb's still work on these computers?
        It's not that someone is deleting the records. It's that they are disappearing on their own. Some malfunction in either the network or the app. That's the scary part. Not a social problem.


        • #19
          Re: Losing records VERY WORRYING

          Please clarify. when you say disappear do you mean deleted? Or do you mean that the record continues to exist But fields have been blanked out?


          • #20
            Re: Losing records VERY WORRYING

            One other question? You are running shadowed tables, right????

            On an older network a non shadowed app just might be beyond the threshold of it's ability.

            Alpha would show a network problem in most cases, but if it does not see an error, it cannot.


            • #21
              Re: Losing records VERY WORRYING

              No shadowed tables here..that I'm aware of anyway. I don't have full control of the network but if that's an issue I'll have to look into doing something about it.


              • #22
                Re: Losing records VERY WORRYING

                I think someone said(I have not verified) that a nonshadowed app would nee 1 gig of memory per user at a time and that is if there is no other traffic on the server. Shadowed takes much of the load off the server. It still has data and index to contend with, but all forms, reports, etc and the associated calculations can be done on the work station.

                An old way to check a card(because we had nothing else then) create a very large zip file of over 200 megabytes. copy it to and from the server from a workstation and repeat for each workstation while you time it. Then try it between workstations. There are other tools today, but if you don't have them???


                • #23
                  Re: Losing records VERY WORRYING

                  This has been hapening to me too, random record overwrites. The linking field is blanked. I do not use referential integrity and the only thing the users can do is the scripts I have attached to buttons or events, there are no toolbars at all.

                  I have tried to narrow down at what point in the process this happens. I have a 6 user system. The main form is very complex and has 3 browses and about 10 tables in a set displaying information. It always happens when saving the record (which is triggered by an on change event).

                  In the onarrive event i record the field value then in the onchange event I look at the value again save the record and write to an audit trail if the values are different. I also check a PIN number for the user entering the data to capture that info.

                  I am using dbf files using a NAS as the storage unit. I have some units shadowed and others not, just to see if there is a diference. There are several hundred changes a day and I seem to "lose" a record every third day or so. There is no way directly for them to erase the linking field as it does not even appear on the form.

                  I cannot pin it down and have spent an inordinate time trying to. It is very bothersome to tell folks to trust the system and it deletes their records. The only good thing is it happens right in front of them and they can start a new record, but I have very little trust from my group.


                  • #24
                    Re: Losing records VERY WORRYING

                    You're lucky. In my case they even print out a report with the record which often disappears and they don't even know it. Until you go back to change something and the record isn't there--or someone else has used the record! Or there are two with the same number!

                    Pretty crazy and I haven't figured it out either.


                    • #25
                      Re: Losing records VERY WORRYING


                      I have limited experience with clients using NAS devices instead of PC's or Servers. But my experiences have been bad. In all cases the clients have gone back to full PC or server to handle the data.

                      My personal practice is to use complex sets for reports, or readonly forms, never for data entry. A ten table set qualifies as complex.

                      One other possibility, you may be mixing form based code with table based code. This, in my experience, is problematic and should be avoided.

                      Have you investigated potential issues with "opportunistic" locking settings on the work stations?

                      Are your work stations running operating systems that didn't exist when A5v8 was released?


                      • #26
                        Re: Losing records VERY WORRYING

                        Sorry, I haven't been here a while, so I just saw the replies now.
                        Yes, all my users have the database shadowed. I have narrowed it down to just the same as John says - the record disappears on save.
                        It is not deleted, but all data is blanked - I am left with a record that has no data. No, it's definitely not a user deleting data - it is something that Alpha does by itself.
                        There is a Customer ID that is auto-incremented, and a couple of other calculated fields - a user has no way of deleting them. They get emptied just like everything else.
                        I don't use referential integrity, so all the child tables a left intact - it is only the record in the main table that gets 'emptied'.
                        I know that it happens at 'save', because it happened twice, a few days intervals, to two different users. I told them to click 'save' before they start editing a record, just to make sure the data is safe. That was a mistake - they both report that all data simply vanished on clicking 'save'. The 'save' button doesn't do anything else - it's the standard 'save record' action script, that has just one line of code :topparent.commit()
                        I use the standard Alpha dbf files. The form this happens in, is built on a set with one main table and two child tables - one to hold memo fields, and one to hold contact info for customers - a one to many link.
                        There is a small browse embedded, otherwise is just a standard Alpha form, nothing special except it's the most used form in the application.
                        normally I only loose a record every few months, but it is worrying to the point that I'm wondering if I have to switch to mySQL tables or find an alternative to Alpha altogether. This is not the only customer that reports the problem, but it is the one where it happens most frequently.
                        One thing that is different with this customer is that all user profiles are stored on the server, not on the local computers. The shadow, however, is on the local hard disk.

                        EDITED to say that this customer is using version 10.5 of Alpha, the other customer where this happens to a significant degree uses version 8. They both use a mix of Windows XP and Windows 7, with a Windows Server 2008 as server OS.
                        Last edited by mariusm; 12-12-2013, 06:55 PM.
                        It is easier to get older than wiser


                        • #27
                          Re: Losing records VERY WORRYING


                          Thanks for the potential info. I am trying right now to have an edit button by some of the fields i made read only so I can see if it happens when they edit in a new form with only one table. Time will tell. I am probably mixing code and I have to look at that. I have read a bit about the opportunisitic locking but I thought it had to do with the servers and not the work station. Presently I am using v11 on everything.
                          It is so very strange but I will keep tinkering.


                          • #28
                            Re: Losing records VERY WORRYING


                            I added this to my autoexec some time ago, which I believe should turn this off on the client side:
                            if registry.sys_get("HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\OplocksDisabled")<>"1"
                            end if

                            This was done a year ago, and still the vanishing problem exists.


                            • #29
                              Re: Losing records VERY WORRYING

                              John, in any of my data entry forms that include autoinc fields I always begin the new record with a button push that runs a script which begins the new record and then immediately saves the record. This has the salutary effect of locking down the autoinc field value. The user then proceeds to finish the new record in CHANGE mode, not ENTER mode, if you see what I mean. In doing this I've made the design choice that I'd rather write code to delete a partially filled record if the user cancels the "new" record, than to rely on the form to change the autoinc field value after the record has begun, as will happen if someone else on the network saves their new record first. Others may choose differently of course.


                              • #30
                                Re: Losing records VERY WORRYING

                                Thanks for the reply. I do the same thing and save the record prior to data entry and continue in change mode. My records that are having the linking field blanked out are the children. This is happening after an edit and selecting save via script and the on change event. The parent has the auto incr field and the child is created and saved with the same number. After editing, the numerical field is blanked that is all, which makes it appear to the user as though it's gone.