DataPage Question

[B. Jacobs]

I am running 3.7MR3. I have Datapage turned on for a program. When I run a program in 3.5MR2 with Datapage, it updates only the info for the part I am running. Now when I am in Datapage running in 3.7MR3, it wants to update a lot of different parts. Then I get a mesage about not a good database, then it will update the part I am running.
Is there something I am not doing right?
Thanks

[craiger_ny]

Probably the xstats11.tmp file in one dirrectory (V3.5) is fine and in the other (3.7) it is trashed and keeps getting appended to. Check out this and see if that solves it.

Craig

[B. Jacobs]

I tried what you said Craig. It didn't work for me.
Here is what I get. I am not sure where I am going wrong.
After I hit OK about 6 times it then updates the right file.

[dccfreak]

This happened to me when I first started using it. I had to completely delete the xstats11.tmp file, and let a new one be written.

I know Craig's code does this very thing, but, to avoid any filepath issues or differences, try doing this:

1. If you don't fear there may be any chance of possibly losing any data you feel might still be in the file, then simply go into the 3.7 root program directory and delete the xstats11.tmp file, then run the program again to see if this solves things.

2. If you do fear, then create a temp folder in the 3.7 program directory and place the xstats file in there (it shouldn't make a difference but I like to eliminate all room for errors), remembering to rename the file slightly like adding a 1 or something to the end of the filename. Now run the program and see what happens.

Being that it works for one version but not the other tells me that it shouldn't be a database lock error or corruption, but, rather something in the version directory settings (like the xstats file). At least that is all I can think of, but, this is the same issue I ran into and that is how I fixed it. HTH

[cappel]

Alright I have had his exact problem. This is how it is fixed.

1. Inside PC-DMIS goto
- insert
- statistics command
- statistics
2. hit the delete current stats file about a dozen times.
3. Close PC-DMIS
4. Open datapage editor
5. Open the database that you have been dumping the data to
!!!!!!Stop!!!!!!!!
At this point it is critical that all applications of datapage, besides the editor, are closed, and make sure that if you have another CMM that might update datapage.
6. goto
- database
- unlock
7. Hit ok on the three windows that open up.
8. goto
-database
-close
9. close database editor

This should work for you. If it does not, I have some other ideas for you.

Fred

[B. Jacobs]

This happened to me when I first started using it. I had to completely delete the xstats11.tmp file, and let a new one be written.

I know Craig's code does this very thing, but, to avoid any filepath issues or differences, try doing this:

1. If you don't fear there may be any chance of possibly losing any data you feel might still be in the file, then simply go into the 3.7 root program directory and delete the xstats11.tmp file, then run the program again to see if this solves things.

HTH

I did just that. I went into the PC-DMIS folder and deleted the file.
It is working fine now.

Thanks

[craiger_ny]

That code I posted on deleting the xstats11.tmp needs to be at the very beginning of the program by the way. I'm not sure if I mentioned that.

Craig

[Matthew D. Hoedeman]

Too many people get their panties in a bunch about deleting the XSTATS11.TMP file. Just delete it. Some want to rename it, 'just in case there is something in there you might need' or there are some who worry about what it will do to Pcdmis.

Well, it is NOTHING other than a TEMPORARY file (.tmp) that holds raw data that had been dumped from Pcdmis AFTER you measure a part. The worst that could happen IF you just plain delete it is that you might have to re-measure a part. However, if it CAN NOT update Datapage, then the data just keeps on building up in the file and it will not be deleted. You said you saw it update a LOT of Datapage parts, that is because if there is ANY error in the update, then it will not empty the file. So, all that data it sent to Datapage is already in there. I am not sure what this will do to the size of the database since once something is put in it, it is there forever, even if you delete it later and it will NOT get written over, so it just keeps getting bigger, like the Blob.

Anyway, in the WAY past, I came up with a simple BATCH file that has a short-cut on the quick-start bar (windows) and before I start a study of ANY kind, I simply click on it (once) and it deletes ALL the copies of XSTATS11.TMP that I might have in ALL of my Pcdmis directories and replaces it with a 'master blank' XSTATS11.TMP file (gives me something I know is not corrupted in anyway to start with).

Booger-boy's method is also good, but YOU have to remember to put the code in the program. My way is good also, but YOU have to remember to click on the icon. My batch file also deletes all the files in my Datapage dump directory. This directory is ONLY for raw data dumped from Datapage when I am done running a study and it is the data I use to COPY and PASTE into my custom forms. This keeps the directory from filling up with old data that I don't need.

DELETING XSTATS11.TMP: This is the FIRST thing you want to do if you EVER get any kind of an error when updating Datapage. Just delete it. You can always SEND CURRENT STATS TO FILE for the part you just ran, the data is still there. As long as you DO NOT QUIT out of the program (close and or save work the same) you can go back and re-send the data and try again.

[craiger_ny]

........DELETING XSTATS11.TMP: This is the FIRST thing you want to do if you EVER get any kind of an error when updating Datapage. Just delete it. You can always SEND CURRENT STATS TO FILE for the part you just ran, the data is still there. As long as you DO NOT QUIT out of the program (close and or save work the same) you can go back and re-send the data and try again.

Absolutely positively. First thing you should always do. First thing anyone will ask is "did you delete the xstats11.tmp file?" Delete it and don't feel bad about it. I should write a VB app that deletes every single xstats11.tmp file on a system. I could make it look like a toilet, maybe I could make it look like a rocket launcher and have it display a mushroom cloud when you hit the big red button, maybe it could look like a door getting slammed in the face of a half drunk half dressed crack ho........wait a minute, wrong thread.

Delete it with a vengeance.

Craig

[Paul Barriage]

http://baggy3.info/2centani.gif
Two cents comin,.....


Did I see a dash (-) in your part name??

[Matthew D. Hoedeman]

http://baggy3.info/2centani.gif
Two cents comin,.....


Did I see a dash (-) in your part name??

Now here's a FUNNY thing about using the MINUS (or 'DASH' if you prefer) in your program name:

When you create a NEW program, you enter the name "27215-100-1" and that name will show up as the name of the program IN THE EDIT window. This is also where it will save the data in Datapage, under part 27215-100-1. HOWEVER, if you, in the edit window, type that in for the program name, you will get 27114 as the program name and that is where it will save the data in Datapage.

NOW, I have long been a bitcher about people using that symbol in feature ID's and dimension ID's in their programs. We have ALL (or almost all) seen what this can and will do to programs. HOWEVER, I have a dirty little secret: I use the - sign in almost ALL my program names. HOWEVER, there is also always alpha's in the name as well. 27215-100-STH for example, or 27215-100-AL. I have never had a problem in 17 years of using this method with Pcdmis and Datapage. Of course, now that I have said this, 15,273 problems will now crop up and bite me in the butt. As long as it is a mix of numbers and letters and ONLY when used in the program name, the minus sign has NOT been a problem of ANY kind for me, ever.

OH and by the way, Pcdmis defaults to the use of the - sign in program names. When you create a new program and you enter a value for PART, REV, and SERIAL, it will delineate these fields in teh default save file name with a space, a dash, and another space. The spaces make it a NON-MATH function by forcing alpha's into the name. I simply eliminate the spaces (more or less) since I use other alpha's in the name anyway.

[craiger_ny]

NOW, I have long been a bitcher about people using that symbol in feature ID's and dimension ID's in their programs. We have ALL (or almost all) seen what this can and will do to programs. HOWEVER, I have a dirty little secret: I use the - sign in almost ALL my program names.....

Ha ha, same here. 6203-12-082-D is my program name format (that is one of our part numbers). It has never been a problem in regars to Datapage for me.

Craig

[Matthew D. Hoedeman]

Ha ha, same here. 6203-12-082-D is my program name format (that is one of our part numbers). It has never been a problem in regars to Datapage for me.

Craig

AH, but you are ALSO mixing the alpha-numeric so that it is no longer a subtraction equation for Pcdmis. As long as you do not try to use the program name in anyway INSIDE pcdmis (like in an assignment), it will not be seen as subtraction. Datapage itself doesn't care.

[T Miller]

I also use the - dash in program names and never had a problem with datapage or pcdmis

[Paul Barriage]

Well,...... I know I will get slammed again for this......but cant resist the urge to help.


Substitute an underscore for dashes.

After 1 1/2 years of running parts for one customer, using dashes, 1 program out of 150+ decided it didn't like the dash. It sent a string to datapage that KILLED the database. It came up as a critical error,....too many users, or illegal character,..... blah, blah,......it died. After 2 hours of looking through the data, and using 2 other databases, I recovered most anything that was not that one part. After experimenting to see what caused it,.....the dash was the issue.

Feel free to use the dash if you like.
http://baggy3.info/2centani.gif