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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PB7 Compile Problem

Status
Not open for further replies.

bigbillmac

Programmer
Jan 31, 2005
24
GB
I am running PB7 in windows 2000 and it has compiled programs in the past OK.
BTW compilation is to machine code!
Now all of a sudden it has stopped compiling and gives the following error message:
Codegen compilation error, see file 'C:\DOCUME~1\bill\LOCALS~1\Temp\new_main.log'.

When you look at this file it gives a whole load of C errors - can I attach files in this forum? If I could you will see that the file gives NO clues to the problem.

This occurs on ALL applications now, nothing will compile. I even created the most simple application possible, ie just an app object with no code and this will not compile.

What is happening? Help

Bill
 
Bill,
Apparently some win.ini file or some other windows file or registry setting seems to be messed up on your machine. Can you try compiling the same app from another PB machine and see if this works?
Also can you either attach a file or just cut & paste some sample text from that log file.
- A0C61ZZ
 
Hi A0C61ZZ,

Let me bring you up to date!

I uninstalled PB7 and renamed the \program files\sybase directory to \program files\sybase_10. I then reinstalled PB7 and lo and behold it worked. I then applied the final EBF for PB7 and this was all fine and dandy, I thought I had cracked it.

So I thought, I can run two directrories:
\program files\sybase_10
\program files\sybase_7
and simply rename the one I want to run (ver 7 or 10), to \program files\sybase just before I run it. Not particularly elegant I know.

But after running PB10 and then going back through the renaming process to run PB7 it will no longer do a machine code compile. So, the act of running PB10 cocks up PB7.

So, it would seem we have an issue of files and registry entries.

I haven't bothered to try another machine, because I run the test with the most simple PB app possible, ie just an app object with no code. I did this just to eliminate the possibility that my code was causing problems.

There is a way round this and that is to forget the machine code compile and do the non-machine code version, ie the one that produces .pbd instead of .dll files. This compile works fine, I think I may not have mentioned that fact earlier, and my customer is more than happy. It seemed strange because I haven't used this version since the machine code compile was first introduced, back in ver 4 or 5 - I think.

My main client is still using some win98 machines (they are waiting for this project to go live before they change hardware and OS). The reason they are still using Win98 boxes is because the version of software this project will replace is a DOS based program. Its a Clipper app I wrote for them many years back - it uses the Advantage database. PB10 will only work on XP and 2000, so you can see I am stuck for a while.

Bill
 
Bill,
There's a very high likelihood of renaming the \program files\sybase directory to \program files\sybase_10 & sybase_7 (back & forth) having messed up the registry entries.
I'm assuming you changed the directory names manually, which by the way would have left the PB 7.0 & 10.0 installation registry entries in an inconsistent state.

Check the directory paths in the registry entries HKEY_CURRENT_USER\SOFTWARE\Powersoft (or sybase) & HKEY_LOCAL_MACHINE\SOFTWARE\Powersoft (or Sybase)

Also let me know what is the final outcome of this issue?
A0C61ZZ
 
No, I manually rename one of them back to \program files\sybase before I run - so I can only run one of them at a time.

I tried installing PB7 in another directory and this was fine until I applied the EBF, which wanted to put most of its files in: \program files\sybase - irregardless of where I installed PB7!

I am getting round this by NOT supplying a machine code version of the app.

Bill
 
Before re-installing PB have you tried uninstalling the existing version of PB.
That's a problem with PowerBuilder. We had similar issues (writing to the same Program Files directory) with PB 6.5 & 8.0 when we tried a reinstall. It used to find the existing directory and believing PB existed it never did a complete and consistent install.
- A0C61ZZ
 
<<Before re-installing PB have you tried uninstalling the existing version of PB.>>
I assume you mean the PB10 version? No, I haven't bothererd but I am pretty sure it will work - its basically what I am doing by renaming the c:\program files\sybase directory when I want to run a particular version.

<<We had similar issues (writing to the same Program Files directory) with PB 6.5 & 8.0 when we tried a reinstall. It used to find the existing directory and believing PB existed it never did a complete and consistent install.>>
I don't know if you have used many install program builders, but it's generally one of the properties you can set for the files in the install - ie does it overwrite newer versions and you would usually (if not always) say NO to this question. That's why simply reinstalling PB7 does not work.

I have to say that Sybase could have made my life a lot easier by warning about this. I have also had trouble logging in to the support site recently and I have emailed the contact address and no one has bothered to reply - this is not good. As a product I really rely on PowerBuilder.

I shall just have to wait until my client has finished upgrading their Win95/98 boxes to win2000. In a way it's my fault they are still using win95/98 because they are still running the DOS (Clipper compiled) version of the software I wrote for them some time ago (OK OK a long time ago).

Then I will be able to migrate to PB10 and forget about the nightmare that was PB7. Just as an example I had a really odd problem this morning when a piece of code that is triggered by a RowFocusChange event wasn't being triggered. Your immediate reaction is that you have made a balls up (technical jargon for mistake) and you look at the code and cannot see a problem. Close down PB7 and immediately reopen it (no need to reboot, it's not the OS at fault) and Eh Voila it works OK. You get memory faults in the most odd places, yesterday it memory faulted on 'global search' from the library painter, again close/repopn and all is kosher again.

My experience with PB10 is that it has none of these little nasties - or very few anyway. The real problem with PB7 is that at any time when you get a memory fault it can corrupt the PBL containing the app object and then you have a little problem putting all back again.



Bill Mac
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top