My company is running an old version of FM 4.0 pro. The main folder for the program is a share on a windows 2003 server machine. We have it set up to use the host/guest configuration and for some reason when ever a report is printed, it prints a duplicate. I have searched high and low but could not find any settings that may cause this. This problem happens on several differnt printers and all users have this issue, so I can not narrow it down to one printer or one user. Any ideas are welcome, thank you!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Prints page twice, why?
- Thread starter fizgig420
- Start date
Can we merge our problems? I have a customer with XP and FMP won't print 2 copies on one particular printer!
This is pure guesswork. You could well have a driver problem with an 'ancient' FMP and a modern OS.
Did the DB ever work properly? Do other FMP DBs work OK? Try creating a new simple DB that prints a report. If it behaves properly, your main DB could be corrupted - re-build it.
Is it all reports?
What about other applications?
I don't know what it would achieve but what happens if you change the number of copies to 2?
Cheers,
Paul J.
This is pure guesswork. You could well have a driver problem with an 'ancient' FMP and a modern OS.
Did the DB ever work properly? Do other FMP DBs work OK? Try creating a new simple DB that prints a report. If it behaves properly, your main DB could be corrupted - re-build it.
Is it all reports?
What about other applications?
I don't know what it would achieve but what happens if you change the number of copies to 2?
Cheers,
Paul J.
- Thread starter
- #3
Thanks for your post, I wish I could trade my problems with you! I was thinking that it may be a driver problem as well but we have tried printing from 6 different pc on 3 different printers, each printer does have its own driver and on top of that I did try installing an updated driver on one pc that has a printer attached to it, still prints twice. We only have one DB, and it did become corrupt and I had to do a recovery but that happened after the program started printing things twice. It was printing fine about 2 weeks ago, don’t have any info on what may have changed. Other apps print fine, no probs. Great advice on creating a new simple DB to test with, I will try that, thanks!
When we are about to print, we do a search then sort, then it brings up the report in preview mode, then its pauses - then you click continue to print. So, instead of clicking continue to print, I went to the file menu and tried printing from there - worked like a charm, only one copy came out. I then clicked continue on the script and it printed two. Could it be a glitch in the script or FM software?
Thanks,
Mike J.
When we are about to print, we do a search then sort, then it brings up the report in preview mode, then its pauses - then you click continue to print. So, instead of clicking continue to print, I went to the file menu and tried printing from there - worked like a charm, only one copy came out. I then clicked continue on the script and it printed two. Could it be a glitch in the script or FM software?
Thanks,
Mike J.
That sure sounds like a glitch in the script. Any users playing?
FMP is pretty unlikely. Its bugs tend to be rather strange; rarely everyday stuff.
On the other hand, your file could be corrupt. Sometimes you get corruption before FMP decides it's had enough and tells you. Did you Recover and then import your data into an old (good?) copy of the file? I don't either but have recently found a number of gurus saying never to use a Recovered file, just get the data frm it.
Cheers,
Paul J.
FMP is pretty unlikely. Its bugs tend to be rather strange; rarely everyday stuff.
On the other hand, your file could be corrupt. Sometimes you get corruption before FMP decides it's had enough and tells you. Did you Recover and then import your data into an old (good?) copy of the file? I don't either but have recently found a number of gurus saying never to use a Recovered file, just get the data frm it.
Cheers,
Paul J.
- Thread starter
- #5
Well, I have tried a few things now. I have downloaded the trial version for FM pro 6.0, installed on the server, converted the DB and everything took just fine. It did not fix the issue. It still prints two copies while using the script. I also installed in on single pc with the DB file on the local drive, nogo. I have since put 4.0 back on the server. The other issue is each time I startup the program on the server it says that the file was not closed properly the last time and it will check for consistancy. It seems like the DB is damaged beyond repair. Another problem is sometimes when I click to open print setup from the file menu, the program crashes. As for the recovery. I had to do another one today. We are using the recoved file for the DB. It renames it recoved then I just rename it to the oridiginal file name, I guess this is not the best thing todo. Should I start looking into exporting the data into a new file? Oh well, there has to be an answer somewhere,lol
Thank you for your get suggestions!
Mike J
Thank you for your get suggestions!
Mike J
Yep, I'm told by people who know more than I do that a Recoverd file is a disaster waiting to happen.
Certainly sounds like a re-build.
Just to make you feel better. My customer with the 2 copy problem. Suddenly out of the blue, the number of copies in the print dialogue went to 1. I brought home a copy f the DB to have a look. It's set to 2. As if life wasn't difficult enough!
Cheers,
Paul J.
Certainly sounds like a re-build.
Just to make you feel better. My customer with the 2 copy problem. Suddenly out of the blue, the number of copies in the print dialogue went to 1. I brought home a copy f the DB to have a look. It's set to 2. As if life wasn't difficult enough!
Cheers,
Paul J.
- Thread starter
- #7
Paul is right...problem can be in the recovered file...
NEVER use a renamed-recovered file...
Make sure you have always an empty basic file fron all your files (save copy as clone-no records)
Import the records from the recovered file into this empty file and check for errors - delete the recovered and damaged file.
If everything is OK, save again an empty clone no records file....
HTH
John
NEVER use a renamed-recovered file...
Make sure you have always an empty basic file fron all your files (save copy as clone-no records)
Import the records from the recovered file into this empty file and check for errors - delete the recovered and damaged file.
If everything is OK, save again an empty clone no records file....
HTH
John
- Thread starter
- #9
That is exactly the problem, before I started working with their systems, they had to recover this file a number of times and always had just renamed the recovered file. From what your saying that is a bad idea! I downloaded the trial version for FM pro 6.0 and created a new file, then just copied our layouts over and setup the printing script then brought 1 record in to test with. Worked awesome, no more printing issue when just the individual records are imported into the newly created layouts. Now, the next problem is the 1288 records that need to be exported from the old DB file. Is there a way to pull them out all at once or do they need to be exported individually? Thanks for your input John!
Mike J.
Mike J.
You can import all the records at once...should be no problem...
...but do a check on the imported records/data since they are coming out of a (several times) recovered file....
One point that I forgot about the clone/no records...
There are, however, caveats when using stored data (like graphics for buttons) in global container fields:
There is a possibility that you wipe out all data in those fields.
To remedy the problem of graphics and other global values being cleared out when a database is saved as a clone, try using a 'preference' file.
It's possible to reference stored graphics through a relationship to a preferences file so they are less likely to be cleared out....
It comes down to the system of good building/develop...
and it takes some time before you have the good one...well...before 'I' had the good one....;-)
HTH
John
...but do a check on the imported records/data since they are coming out of a (several times) recovered file....
One point that I forgot about the clone/no records...
There are, however, caveats when using stored data (like graphics for buttons) in global container fields:
There is a possibility that you wipe out all data in those fields.
To remedy the problem of graphics and other global values being cleared out when a database is saved as a clone, try using a 'preference' file.
It's possible to reference stored graphics through a relationship to a preferences file so they are less likely to be cleared out....
It comes down to the system of good building/develop...
and it takes some time before you have the good one...well...before 'I' had the good one....;-)
HTH
John
- Thread starter
- #11
Thank you for the head ups, I will make sure about those Global fields. How do you save a clone? Do you just build the layouts, scripts and fields then save the file as a differnt name or is it a more spacific fuction of the program. This is my first time working with file maker and Im not a DB programer so it is somewhat new to me. I am going to keep plugging away and try to put this mess back togeather. Thanks again!
Mike J.
Mike J.
I save it (File - save as - clone no records)with the same name BUT on a different disk.
1. T o make sure the relationships are not broken
2. To avoid that FM is pointing to an 'empty' file in the 'live' system.
FM can do that in a multi-user/server/peer-to-peer.
It is searching for a file with a 'name' and stops when it find a file with that name.
For now I burn them on a CD, with a log file for all the changes made to the files.
After every change (field, layout, calculation etc) in the 'live' system, a new empty clone to make sure to have an 'empty set of files' as exact copy of the 'live system'.
It's something completely different than a back-up....
1. T o make sure the relationships are not broken
2. To avoid that FM is pointing to an 'empty' file in the 'live' system.
FM can do that in a multi-user/server/peer-to-peer.
It is searching for a file with a 'name' and stops when it find a file with that name.
For now I burn them on a CD, with a log file for all the changes made to the files.
After every change (field, layout, calculation etc) in the 'live' system, a new empty clone to make sure to have an 'empty set of files' as exact copy of the 'live system'.
It's something completely different than a back-up....
- Status