Working on problem, thanks for driver help

I tried 8.01.02 to replace my old one, but the problem persists.

I will keep trying newer versions, but I thought I might post a description=
of the problem in the meantime in case someone has seen it or has suggesti=
ons.

In my app. I have a subform which has a tab control with student informatio=
n, and the form source is table tStudents, a postgres table.

This form is embeded in another form, fMain.

Odd thing is, if I do a Ctrl-V to paste text into a text box on the tab, th=
e form moves to a new record and pastes the data there instead of to the or=
iginal record that was displayed! The form has moved to the new record bef=
ore the 'before update' event of the text box has fired.

This happens if I paste into a box on either tab page. You don't notice it=
at first because all the rest of the boxes continue to display the data of=
the original record, until you click on another tab. Then all the boxes s=
how the new unwanted record, and there the pasted data is.

Ctrl-X (cut) has the same problem. Things look good at first, then you not=
ice that you removed data from a different record that the form has moved t=
o!

It doesn't happen when I copy all the postgres data into a local access tab=
le and then use it as the record source instead of the postgres table. Thi=
s is what makes me think it may be an odbc driver issue.

Ctrl-V and Ctrl-X are windows functions (I'm on Win XP Professional, not su=
re which SP) so concievably Win is part of the problem. I will set up a bo=
x with an earlier version of XP and see what happens.

This app has been running smoothly for years, and through several updates t=
o the backend postgres database.

Thanks in advance for any help, if I solve it I will post a solution.

Fred


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Working on problem, thanks for driver help

Hello,

It's hard to understand your problem. When did your problem appear? Show
us your ODBC + PostgreSQL relative code.

Fred Parkinson wrote:
> I tried 8.01.02 to replace my old one, but the problem persists.
>
> I will keep trying newer versions, but I thought I might post a description of the problem in the meantime in case someone has seen it or has suggestions.
>
> In my app. I have a subform which has a tab control with student information, and the form source is table tStudents, a postgres table.
>
> This form is embeded in another form, fMain.
>
> Odd thing is, if I do a Ctrl-V to paste text into a text box on the tab, the form moves to a new record and pastes the data there instead of to the original record that was displayed! The form has moved to the new record before the 'before update' event of the text box has fired.
>
> This happens if I paste into a box on either tab page. You don't notice it at first because all the rest of the boxes continue to display the data of the original record, until you click on another tab. Then all the boxes show the new unwanted record, and there the pasted data is.
>
> Ctrl-X (cut) has the same problem. Things look good at first, then you notice that you removed data from a different record that the form has moved to!
>
> It doesn't happen when I copy all the postgres data into a local access table and then use it as the record source instead of the postgres table. This is what makes me think it may be an odbc driver issue.
>
> Ctrl-V and Ctrl-X are windows functions (I'm on Win XP Professional, not sure which SP) so concievably Win is part of the problem. I will set up a box with an earlier version of XP and see what happens.
>
> This app has been running smoothly for years, and through several updates to the backend postgres database.
>
> Thanks in advance for any help, if I solve it I will post a solution.
>
> Fred
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaste
--
Andrei Kovalevski
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Re: Working on problem, thanks for driver help

This is strange indeed. Could be an Access issue though. Which version=0D
of MS Access are you using? Also I'm guessing something as bizarre as=0D
this could happen if your parent-child relationships between your forms=0D
changed and somehow the field you are pasting into or cutting text out=0D
of is one of the parent-child fields.=0D
=0D
What are your parent-child fields set to on your master/sub forms? How=0D
this could happen without you actually changing the form is if your=0D
postgresql table changed - e.g. you added a field in between another set=0D
of fields. Since linked tables do not refresh without explicitly=0D
refreshing them, your linked primary key field could very well be now=0D
pointing at one of the parent child fields. I would try relinking your=0D
postgresql tables to rule that out as an issue.=0D
=0D
Hope that helps,=0D
Regina =0D
=0D
-----Original Message-----=0D
From: pgsql-odbc-owner@postgresql.org=0D
[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Andrei Kovalevski=0D
Sent: Thursday, February 21, 2008 4:08 AM=0D
To: Fred Parkinson=0D
Cc: pgsql-odbc@postgresql.org=0D
Subject: Re: [ODBC] Working on problem, thanks for driver help=0D
=0D
Hello,=0D
=0D
It's hard to understand your problem. When did your problem appear? Show=0D
=0D
us your ODBC + PostgreSQL relative code.=0D
=0D
Fred Parkinson wrote:=0D
> I tried 8.01.02 to replace my old one, but the problem persists.=0D
>=0D
> I will keep trying newer versions, but I thought I might post a=0D
description of the problem in the meantime in case someone has seen it=0D
or has suggestions.=0D
>=0D
> In my app. I have a subform which has a tab control with student=0D
information, and the form source is table tStudents, a postgres table.=0D
>=0D
> This form is embeded in another form, fMain.=0D
>=0D
> Odd thing is, if I do a Ctrl-V to paste text into a text box on the=0D
tab, the form moves to a new record and pastes the data there instead of=0D
to the original record that was displayed! The form has moved to the=0D
new record before the 'before update' event of the text box has fired.=0D
>=0D
> This happens if I paste into a box on either tab page. You don't=0D
notice it at first because all the rest of the boxes continue to display=0D
the data of the original record, until you click on another tab. Then=0D
all the boxes show the new unwanted record, and there the pasted data=0D
is.=0D
>=0D
> Ctrl-X (cut) has the same problem. Things look good at first, then=0D
you notice that you removed data from a different record that the form=0D
has moved to!=0D
>=0D
> It doesn't happen when I copy all the postgres data into a local=0D
access table and then use it as the record source instead of the=0D
postgres table. This is what makes me think it may be an odbc driver=0D
issue.=0D
>=0D
> Ctrl-V and Ctrl-X are windows functions (I'm on Win XP Professional,=0D
not sure which SP) so concievably Win is part of the problem. I will=0D
set up a box with an earlier version of XP and see what happens.=0D
>=0D
> This app has been running smoothly for years, and through several=0D
updates to the backend postgres database.=0D
>=0D
> Thanks in advance for any help, if I solve it I will post a solution.=0D
>=0D
> Fred=0D
>=0D
>=0D
> ---------------------------(end of=0D
broadcast)---------------------------=0D
> TIP 2: Don't 'kill -9' the postmaste=0D
-- =0D
Andrei Kovalevski=0D
PostgreSQL Replication, Consulting, Custom Development, 24x7 support=0D
Managed Services, Shared and Dedicated Hosting=0D
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/=0D
=0D
=0D
---------------------------(end of broadcast)---------------------------=0D
TIP 9: In versions below 8.0, the planner will ignore your desire to=0D
choose an index scan if your joining column's datatypes do not=0D
match=0D
-----------------------------------------=0D
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended=0D
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.=0D


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Working on problem, thanks for driver help

Thanks for your reply.

There is no real code involved in the issue. My main form, fMain, has a su=
bform, fStudent. When the user picks a student from a drop-down list on fM=
ain, fMain sends the subform fStudent the id of the selected student. Upon=
receiving the student id, the subform makes that student record the record=
displayed for editing by using the code 'Me.RecordsetClone.FindFirst "stud=
ent_id =3D " & cstr(id)' followed by (if no error) 'Me.Bookmark =3D Me.Reco=
rdsetClone.Bookmark'

This part works as desired. I have stepped through the problem and found t=
hat this code is not run when the problem occurs, thus is not causing the s=
ubform to move unexpectedly to the undesired record.

If the user then chooses to edit the (tabbed control displayed) student da=
ta by using the Windows operating system functions ctrl-c, ctrl-v or ctrl-x=
, the form unexpectedly jumps to a new record before the ctrl-? function ac=
ts, and the action is then applied to the new, unexpected record!

As for when it started happening, that is unclear, but probably not too lon=
g ago. At first the users thought they were making a mistake, that they we=
re in error somehow, and didn't bring it to my attention until yesterday.

Clearly I need to find out if something was changed in the recent past: upg=
rade to server, or to workstations (tech support has the habit of making ch=
anges without telling anyone). One of the techs thinks that a Win XP Offic=
e 2002 - Office 2007 compatibility upgrade was done recently on the worksta=
tions, so I will pursue that as well as whatever else I or others can think=
of.

Thank you for considering my problem.

Fred


>>> Andrei Kovalevski 02/21/2008 1:07 AM >>>
Hello,

It's hard to understand your problem. When did your problem appear? Show=20
us your ODBC + PostgreSQL relative code.

Fred Parkinson wrote:
> I tried 8.01.02 to replace my old one, but the problem persists.
>
> I will keep trying newer versions, but I thought I might post a descripti=
on of the problem in the meantime in case someone has seen it or has sugges=
tions.
>
> In my app. I have a subform which has a tab control with student informat=
ion, and the form source is table tStudents, a postgres table.
>
> This form is embeded in another form, fMain.
>
> Odd thing is, if I do a Ctrl-V to paste text into a text box on the tab, =
the form moves to a new record and pastes the data there instead of to the =
original record that was displayed! The form has moved to the new record b=
efore the 'before update' event of the text box has fired.
>
> This happens if I paste into a box on either tab page. You don't notice =
it at first because all the rest of the boxes continue to display the data =
of the original record, until you click on another tab. Then all the boxes=
show the new unwanted record, and there the pasted data is.
>
> Ctrl-X (cut) has the same problem. Things look good at first, then you n=
otice that you removed data from a different record that the form has moved=
to!
>
> It doesn't happen when I copy all the postgres data into a local access t=
able and then use it as the record source instead of the postgres table. T=
his is what makes me think it may be an odbc driver issue.
>
> Ctrl-V and Ctrl-X are windows functions (I'm on Win XP Professional, not =
sure which SP) so concievably Win is part of the problem. I will set up a =
box with an earlier version of XP and see what happens.
>
> This app has been running smoothly for years, and through several updates=
to the backend postgres database.
>
> Thanks in advance for any help, if I solve it I will post a solution.
>
> Fred
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaste
--=20
Andrei Kovalevski
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/=20




---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: Working on problem, thanks for driver help

This is a resend, pardon if it went already; I got no copy so I suspect it =
never went.

Thanks for your reply.

There is no real code involved in the issue. My main form, fMain, has a su=
bform, fStudent. When the user picks a student from a drop-down list on fM=
ain, fMain sends the subform fStudent the id of the selected student. Upon=
receiving the student id, the subform makes that student record the record=
displayed for editing by using the code 'Me.RecordsetClone.FindFirst "stud=
ent_id =3D " & cstr(id)' followed by (if no error) 'Me.Bookmark =3D Me.Reco=
rdsetClone.Bookmark'

This part works as desired. I have stepped through the problem and found t=
hat this code is not run when the problem occurs, thus is not causing the s=
ubform to move unexpectedly to the undesired record.

If the user then chooses to edit the (tabbed control displayed) student da=
ta by using the Windows operating system functions ctrl-c, ctrl-v or ctrl-x=
, the form unexpectedly jumps to a new record before the ctrl-? function ac=
ts, and the action is then applied to the new, unexpected record!

As for when it started happening, that is unclear, but probably not too lon=
g ago. At first the users thought they were making a mistake, that they we=
re in error somehow, and didn't bring it to my attention until yesterday.

Clearly I need to find out if something was changed in the recent past: upg=
rade to server, or to workstations (tech support has the habit of making ch=
anges without telling anyone). One of the techs thinks that a Win XP Offic=
e 2002 - Office 2007 compatibility upgrade was done recently on the worksta=
tions, so I will pursue that as well as whatever else I or others can think=
of.

Thank you for considering my problem.

Fred


>>> Andrei Kovalevski 02/21/2008 1:07 AM >>>
Hello,

It's hard to understand your problem. When did your problem appear? Show=20
us your ODBC + PostgreSQL relative code.

Fred Parkinson wrote:
> I tried 8.01.02 to replace my old one, but the problem persists.
>
> I will keep trying newer versions, but I thought I might post a descripti=
on of the problem in the meantime in case someone has seen it or has sugges=
tions.
>
> In my app. I have a subform which has a tab control with student informat=
ion, and the form source is table tStudents, a postgres table.
>
> This form is embeded in another form, fMain.
>
> Odd thing is, if I do a Ctrl-V to paste text into a text box on the tab, =
the form moves to a new record and pastes the data there instead of to the =
original record that was displayed! The form has moved to the new record b=
efore the 'before update' event of the text box has fired.
>
> This happens if I paste into a box on either tab page. You don't notice =
it at first because all the rest of the boxes continue to display the data =
of the original record, until you click on another tab. Then all the boxes=
show the new unwanted record, and there the pasted data is.
>
> Ctrl-X (cut) has the same problem. Things look good at first, then you n=
otice that you removed data from a different record that the form has moved=
to!
>
> It doesn't happen when I copy all the postgres data into a local access t=
able and then use it as the record source instead of the postgres table. T=
his is what makes me think it may be an odbc driver issue.
>
> Ctrl-V and Ctrl-X are windows functions (I'm on Win XP Professional, not =
sure which SP) so concievably Win is part of the problem. I will set up a =
box with an earlier version of XP and see what happens.
>
> This app has been running smoothly for years, and through several updates=
to the backend postgres database.
>
> Thanks in advance for any help, if I solve it I will post a solution.
>
> Fred
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaste
--=20
Andrei Kovalevski
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/=20




---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate