Sybase error related to "pbdwe.dll"

[imivandi]

Hi Everyone,
I have an application(PB 8.0) which ran properly so far, but I put a modification in it and after a build a user got an error message randomly: "Sybase Inc. Product file has encountered a problem and needs to close. We are sorry for the inconvenience."When I click on the debug,I got this: "Error signiture: AppName:tipex.exe AppVer:8.0.3.9838 ModName: pbdwe80.dll ModVer: 8.0.3.9838 Offset: 000fa39d"

As I wrote on the web pbdwe80.dll is for the forms and reports. The most important thing is that I have never got such an error message when I run the built application. But I'm the developer so I have an installed PB 8.0. The user has a pdwe80.dll on his computer and earlier he has no problem with the application.

I have no idea how to solve it.
Please help me to find the solution for this.

Thank you so much for your help in advance.

 

[miguelleeuwe]

this is very dificult to solve without knowing more.

1) Does your user have the same version of fixes of PB runtime installed on his computer as you are using?
(you can try to copy your dll to where the user has stored the exe file of the application. If that solves it then he has a problem of versions or his is corrupted.)

2) If you made a change to a datawindow: has it got to do with a change in types of lengths of certain columns? If so, does the user have the same datadefinition? Are there stored procedures involve? Does the user have rights to the table and columns?
this is all just guessing, since even though I'd be right, normally the errors should be diferent.

I'd start to verify the version of the user's runtime dlls.


regards,
Miguel L.

 

[imivandi]

Hi Miguel,

Thank you for your comment/help.
1, I have checked and the user use the save pbdwe80.dll as me in his windows/System32 folder.
(my application is in an msi package and when install dlls are copied to system32)
2,
-Yes, I have made the change on the datawindow, but I just add a new column into the table and add a new column to the datawindow. In the DB it is char(120) in the datawindow the limit is 120.
-"does the user have the same datadefinition?" - The user uses the build Application.
-There is no stored procedure involved..
-User have update and delete right on the table.

I believed that specify update properties caused the problem,"Key and Modified Columns" and "Use update" are ticked.There are 2 primary keys on the table.

User said that once he got 50 times this message, when he changed from the modified screen(this is where I added a new field) to another screen, but next time he did almost the same and didn't got the error message at all.

How come it works and once not?
Thanks for your help.
Henry

 

[miguelleeuwe]

Hi Henry,

I quote what you said:
---------------------
"User said that once he got 50 times this message, when he changed from the modified screen(this is where I added a new field) to another screen, but next time he did almost the same and didn't got the error message at all."

It would really help if your user could trace down the exact secuence of things doing to provoke the error.
You could then do a debug and it might just fail on your computer too. Try the user to describe you exactly what he does, rather than 50 times 'it' goes wrong and 'sometimes' it works well. Check your losefocus events, window activate events, update process, etc. to check if something might interfere when you change focus between different windows.

Another option you might try, is to compile an executable with debug information and then run the exe with the /pbdebug option that will generate a log file.

This sounds like there's something going wrong when windows change focus or when there's more than one update running on diferent windows.
Are you using inherited windows to do your update stuff and other general things? If so, depending on what's coded, one window might be mistaken by the other or funny stuff like that. (I'd have to see the code to know it).

So you are saying that you are sure that the database is the same and the permissions are okay. That leaves the next:

Though the dll you found in windows\system (pbdwe80.dll) is the same version, did you do a find on the whole harddisk and if the executable is on a network, did you check it is not present in that same directory? If not, you can't be sure the one found in the windows system directory is really the one being used.

Can you try to execute the same runtime and executable on another computer at your client? Many users off their pc's by brute force and there might be a diskcheck requiered (to clean up 'lost chains' and that kind of stuff). If it works fine on another pc then check the users hardware and reinstall your application (and pb runtime).


about your update properties in the datawindow:
update properties: using "Key and Modified Columns"

Normally you get less problems by using "key columns" instead of "key and modified columns". If you can, try using this, though it shouldn't just 'explode' it should give you a 'rows changed between retrieve and update' error.
But since there's loads of diferent bugs in diferent versions, you could give it a try.

You could also check if there are triggers of update defined on your table that might have to be recompiled or changed.

about what you said "There are 2 primary keys on the table"
- let me correct you: that is not possible, there might be 2 fields in one primary key, but only one key can be primary on a single table.


Hope it might give you some things to check.
Don't know if it'll be lot of work, but if your application (and database?) are small, you can send me them and I'll try to see what might be wrong.

Miguel


regards,
Miguel L.

 

[miguelleeuwe]

By the way:

After your changes made, how did you distribute them to you user? Did you make just one runtime library and send that one or did you do the right thing:

do a full rebuild, and redistribute the whole application with all pbd's / dll's (if involved)?




regards,
Miguel L.

 

[imivandi]

Hi Miguel,

Hi Miguel,

Thank you so much the tips.

I will check everything what you suggested.
Fist of all:
1. I ask the user to trace the exact tasks he did.
2. There is one window and lots of datawindows on it. When the user said changed the screens, actually there was just one screen and the buttons
just let some of the datawindows shown or not. - I will check the multi update part.
3. This window is inhereted, but there is a multi update in the code and it deals with the updating.
4. After the built msi package is created and it is installed to the user and dll's are copied to his computer. Dll are always the same?
These are not changed after a built process, or a modification,right?
5. So far just one user got the error message. I will test it on another user's PC. Will see...

Thanks again. Soon, I will let you know the results
Henry

 

[miguelleeuwe]

okay,

just for interest: what are you using to do the msi installer?

if it works for other users:
- it must be related to his disk or maybe RAM memory. (lots of RAM/simms are bad, but will work fine up to a certain use of memory and only then start to fail).
- this user does "something" that nobody else does.

try to do changes on all datawindows, and make them invisible and then do the update (if that's posible). maybe one of the datawindows is accesed in a way that can't while being invisible/disabled???

export the window and it's parent and add it to the post if you can't see any problem.


regards,
Miguel L.