RE: [RBASE-L] - Need help with an Enhanced DB Grid

2020-06-25 Thread Stuart Hellman
Karen and Michael,

To begin, no Where clauses being used; neither the from working or the one not 
displaying data.  Tried using a view for the DB grid, but still no data being 
displayed.

Thanks for the suggestions.

Stu


Stuart Hellman
Software Designer
Email:shell...@qmiusa.com
Toll Free:800-446-2500
International: 01 630-529-7111
Extension: 1029
www.qmiusa.com
This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies
From: rbase-l@googlegroups.com  On Behalf Of Michael 
Byerley
Sent: Thursday, June 25, 2020 8:22 AM
To: RBASE-L 
Subject: Re: [RBASE-L] - Need help with an Enhanced DB Grid


  The reason escapes me, but several years back, the single table view became 
the pathway I used without fail.


On Wednesday, June 24, 2020 at 1:19:01 PM UTC-4, Karen Tellef wrote:
Just a stab at this.  Does the original "edit using" command have a Where 
clause on it?  After doing your work on the data, does that Where clause still 
evaluate correctly?

I always do the  PROPERTY TABLE tablename 'REFRESH'  first
99% of the time that works for me.  When it doesn't then I do the CLOSE 
followed by the OPEN

There shouldn't be any reason for this to happen, but the last thing you can 
try is constructing a one-table view and basing the grid on that and refreshing 
it

Karen


-Original Message-----
From: Stuart Hellman >
To: 'rba...@googlegroups.com' 
>
Sent: Wed, Jun 24, 2020 11:47 am
Subject: [RBASE-L] - Need help with an Enhanced DB Grid
The application is building a Bill of Materials on the fly. Make a selection, 
delete all rows in the table (in case a previous selection was changed), 
rebuild the B.O.M., adding new parts. When this is done, display the temp table 
in a DB Grid.

The problem is that the data won’t display. The table is getting built. I can 
see the control flicker on the form when something is updating the table. I’ve 
tried different combinations of  table properties, like POST/REFRESH and 
CLOSE/OPEN, but to no avail. Made a quick and dirty form of just the DB Grid 
and opening this form, the data displays as soon as it opens. I have another 
form that displays existing data in a grid with no problems.

Would like to know if the setting for the DB grid (took the default options, 
selected the columns to be displayed) are incorrect  or the refreshing of the 
table is not being done correctly.

Thanks in advance for  your help.


Stu Hellman

[Image removed by sender.]<https://www.qmiusa.com/>
Stuart Hellman​
Software Designer
Email:
shell...@qmiusa.com

Toll Free:
800‑446‑2500
International:
01 630‑529‑7111

Extension:
1029


www.qmiusa.com<https://www.qmiusa.com/>
This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies
--
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rba...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbase-l/DM5PR16MB183619BDF0D559901FA6C076BB950%40DM5PR16MB1836.namprd16.prod.outlook.com<https://groups.google.com/d/msgid/rbase-l/DM5PR16MB183619BDF0D559901FA6C076BB950%40DM5PR16MB1836.namprd16.prod.outlook.com?utm_medium=email_source=footer>.
--
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbase-l/1f45e4e0-cca6-4c89-bb63-2f93d8de935co%40googlegroups.com<https://groups.google.com/d/msgid/rbase-l/1f45e4e0-cca6-4c89-bb63-2f93d8de935co%40googlegroups.com?utm_medium=email_source=footer>.

-- 
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
--- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbase-l/DM5PR16MB18367406F8551951FE141686BB920%40DM5PR16MB1836.namprd16.prod.outlook.com.


[RBASE-L] - Need help with an Enhanced DB Grid

2020-06-24 Thread Stuart Hellman
The application is building a Bill of Materials on the fly. Make a selection, 
delete all rows in the table (in case a previous selection was changed), 
rebuild the B.O.M., adding new parts. When this is done, display the temp table 
in a DB Grid.

The problem is that the data won’t display. The table is getting built. I can 
see the control flicker on the form when something is updating the table. I’ve 
tried different combinations of  table properties, like POST/REFRESH and 
CLOSE/OPEN, but to no avail. Made a quick and dirty form of just the DB Grid 
and opening this form, the data displays as soon as it opens. I have another 
form that displays existing data in a grid with no problems.

Would like to know if the setting for the DB grid (took the default options, 
selected the columns to be displayed) are incorrect  or the refreshing of the 
table is not being done correctly.

Thanks in advance for  your help.


Stu Hellman

[cid:image703998.jpg@3B97A68E.54379801]<https://www.qmiusa.com/>
Stuart Hellman​
Software Designer
Email:  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:  800‑446‑2500
International:  01 630‑529‑7111

Extension:  1029


www.qmiusa.com<https://www.qmiusa.com/>
This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

-- 
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
--- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbase-l/DM5PR16MB183619BDF0D559901FA6C076BB950%40DM5PR16MB1836.namprd16.prod.outlook.com.


[RBASE-L] - RE: Positioning of popup menus

2018-08-31 Thread Stuart Hellman
Karen & Albert, thanks for the input.

What I was asking about was about the popup menu in the properties:

[cid:image001.jpg@01D44140.9EC17D20]

How do I specify the coordinates of this control?

From: rbase-l@googlegroups.com  On Behalf Of Stuart 
Hellman
Sent: Friday, August 31, 2018 12:00 PM
To: rbase-l@googlegroups.com
Subject: [RBASE-L] - Positioning of popup menus

Greetings all,

When using a popup menu in RBase X, is there a way you can set the coordinates 
as to where the menu will display?  The list of choices is displaying right 
over the field I’m trying to populate. The popup menu shows up right in the 
middle of the form. I’ve tried an ‘ugly’ solution of moving the position of the 
form executing the popup off to the side, but there has got to be a better 
solution.

When doing a CHOOSE command, there is an option to set the TOP & LEFT 
coordinates. I was looking for a similar functionality for the popup menu.


Along the same line, is there a way to highlight an selection on the popup menu 
(again like the CHOOSE command)? This would be useful when setting default 
selections or when user goes back to edit a field, seeing what has been 
selected.


Thank you in advance.


Stu Hellman

--
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

-- 
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
--- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[RBASE-L] - Positioning of popup menus

2018-08-31 Thread Stuart Hellman
Greetings all,

When using a popup menu in RBase X, is there a way you can set the coordinates 
as to where the menu will display?  The list of choices is displaying right 
over the field I'm trying to populate. The popup menu shows up right in the 
middle of the form. I've tried an 'ugly' solution of moving the position of the 
form executing the popup off to the side, but there has got to be a better 
solution.

When doing a CHOOSE command, there is an option to set the TOP & LEFT 
coordinates. I was looking for a similar functionality for the popup menu.


Along the same line, is there a way to highlight an selection on the popup menu 
(again like the CHOOSE command)? This would be useful when setting default 
selections or when user goes back to edit a field, seeing what has been 
selected.


Thank you in advance.


Stu Hellman

-- 
For group guidelines, visit 
http://www.rbase.com/support/usersgroup_guidelines.php
--- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RE: [RBASE-L] - Peculiar Cursor Behavior

2017-07-07 Thread Stuart Hellman
For what it’s worth  (Buffalo Springfield, 1967) ---

I figured out what was going wrong with the FETCH of my cursor. It was a data 
type mismatch.

The Quote# variable was defined as DOUBLE while the Quote# filed in the 
database table was defined as INTEGER.  Changing the definition of the variable 
to the correct data type, things are working as desired.

Something to store in the back of your mind for next time.

From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Albert Berry
Sent: Wednesday, June 28, 2017 2:10 PM
To: rbase-l@googlegroups.com
Subject: Re: [RBASE-L] - Peculiar Cursor Behavior

A possibility,

Put the table alias on all the lookups. (Use the correct ones or course)

Albert

WHERE T1.Quote# = ‘123456’ AND T1.Window = 1 AND T2.CostType = ‘A'  AND 
T2.SnapShotID = 9 AND T1.MasterPart# = T2.MasterPart#')

On Jun 28, 2017, at 10:58 AM, Stuart Hellman 
<shell...@qmiusa.com<mailto:shell...@qmiusa.com>> wrote:

Buddy,

It would look  something like this:

WHERE Quote# = ‘123456’ AND Window = 1 AND CostType = ‘A'  AND T2.SnapShotID = 
9 AND T1.MasterPart# = T2.MasterPart#')

The WHERE clause should be good. As stated before, the DECLARE, and OPEN return 
a 0 (zero). The FETCH doesn’t want to cooperate.

I appreciate the input.

Stu


From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Wednesday, June 28, 2017 10:20 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stu
  Would it be possible to show us final vWhere variable with the actual values.

Buddy


From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 1:11 PM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman

<http://www.qmiusa.com/>

Stuart Hellman

Software Designer

Email:

  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:

  800-446-2500

International:

  01 630-529-7111

Extension:

  1029


www.qmiusa.com<http://www.qmiusa.com/>




.


This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact t

RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-28 Thread Stuart Hellman
Albert,

Thanks for the input.

I have set up the indicators like your example.

I think we are getting side-tracked as my initial problem was a FETCH that gave 
me and End-of-data return code.

Stu Hellman

From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Albert Berry
Sent: Wednesday, June 28, 2017 10:49 AM
To: rbase-l@googlegroups.com
Subject: Re: [RBASE-L] - Peculiar Cursor Behavior

The indicator variables are set at the time of the fetch. The values are 0 and 
1 indicating whether or not the value retrieved is a null. I just declare the 
variables like this — and I only use one for them all. I use the R:Base system 
to identify whether or not the value is null.

SET VAR i1 INTEGER

Albert

On Jun 28, 2017, at 7:46 AM, Stuart Hellman 
<shell...@qmiusa.com<mailto:shell...@qmiusa.com>> wrote:

Dan,

Thanks for the suggestion.

I did try your idea. I defined the indicators setting them to an initial value 
of -9 so I would know that those values changed.  Unfortunately, the FETCH  
command didn’t change the indicator values.

Stu Hellman

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Dan Goldberg
Sent: Tuesday, June 27, 2017 12:27 PM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Shouldn’t you have Indicator in your fetch command? I think the variables that 
hold the indicators should be different as well.


FETCH QteDetail  +   <--Here is where the 406 error code is returned in my 
error variable
INTO vQPart# INDICATOR vInd1, vLength INDICATOR  vInd2, vUMMult INDICATOR  
vInd3

Dan Goldberg



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 10:11 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman

<http://www.qmiusa.com/>

Stuart Hellman

Software Designer

Email:

  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:

  800-446-2500

International:

  01 630-529-7111

Extension:

  1029


www.qmiusa.com<http://www.qmiusa.com/>




.


This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are n

RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-28 Thread Stuart Hellman
Buddy,

It would look  something like this:

WHERE Quote# = ‘123456’ AND Window = 1 AND CostType = ‘A'  AND T2.SnapShotID = 
9 AND T1.MasterPart# = T2.MasterPart#')

The WHERE clause should be good. As stated before, the DECLARE, and OPEN return 
a 0 (zero). The FETCH doesn’t want to cooperate.

I appreciate the input.

Stu


From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Buddy Walker
Sent: Wednesday, June 28, 2017 10:20 AM
To: rbase-l@googlegroups.com
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stu
  Would it be possible to show us final vWhere variable with the actual values.

Buddy


From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 1:11 PM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman

[cid:image001.jpg@01D2F005.CA76ED20]<http://www.qmiusa.com/>

Stuart Hellman

Software Designer

Email:

  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:

  800-446-2500

International:

  01 630-529-7111

Extension:

  1029


www.qmiusa.com<http://www.qmiusa.com>




.


This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit

RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-28 Thread Stuart Hellman
Dan,

I understand what you are saying. In the scenarios that I’m testing I know that 
I will get multiple rows.

Stu Hellman

From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Dan Goldberg
Sent: Wednesday, June 28, 2017 10:10 AM
To: rbase-l@googlegroups.com
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

You do not have to do a cursor for indicators. Just use the select into command.

SELECT T1.MasterPart#, T1.Length, T2.UMMult  into vQPart# INDICATOR vInd1, 
vLength INDICATOR  vInd2, vUMMult INDICATOR  vInd3 +
FROM  T1, SnapPartMast T2 

If vind1 = -1 or vind2 = -1 or vind3 = -1 then
   Goto EndLoop
Endif


Dan Goldberg


From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Wednesday, June 28, 2017 7:43 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Buddy & Dan,

I’m using the indicators to not get an error message when the variable 
retrieved is null.   I know the range of the indicator values, that’s why  
initialized it to the -9. In tracing the code, the indicator values are 
unchanged after executing the FETCH command. That indicates to me that 
something behind the scenes of the cursor, something isn’t right.


Stu

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Wednesday, June 28, 2017 9:26 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart

   The indicator value will only show two values a 0 for non-null and -1 for 
null

Buddy


From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Wednesday, June 28, 2017 9:47 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Dan,

Thanks for the suggestion.

I did try your idea. I defined the indicators setting them to an initial value 
of -9 so I would know that those values changed.  Unfortunately, the FETCH  
command didn’t change the indicator values.

Stu Hellman

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Dan Goldberg
Sent: Tuesday, June 27, 2017 12:27 PM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Shouldn’t you have Indicator in your fetch command? I think the variables that 
hold the indicators should be different as well.


FETCH QteDetail  +   <--Here is where the 406 error code is returned in my 
error variable
INTO vQPart# INDICATOR vInd1, vLength INDICATOR  vInd2, vUMMult INDICATOR  
vInd3

Dan Goldberg



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 10:11 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go so

RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-28 Thread Stuart Hellman
Buddy & Dan,

I’m using the indicators to not get an error message when the variable 
retrieved is null.   I know the range of the indicator values, that’s why  
initialized it to the -9. In tracing the code, the indicator values are 
unchanged after executing the FETCH command. That indicates to me that 
something behind the scenes of the cursor, something isn’t right.


Stu

From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Buddy Walker
Sent: Wednesday, June 28, 2017 9:26 AM
To: rbase-l@googlegroups.com
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart

   The indicator value will only show two values a 0 for non-null and -1 for 
null

Buddy


From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Wednesday, June 28, 2017 9:47 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Dan,

Thanks for the suggestion.

I did try your idea. I defined the indicators setting them to an initial value 
of -9 so I would know that those values changed.  Unfortunately, the FETCH  
command didn’t change the indicator values.

Stu Hellman

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Dan Goldberg
Sent: Tuesday, June 27, 2017 12:27 PM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Shouldn’t you have Indicator in your fetch command? I think the variables that 
hold the indicators should be different as well.


FETCH QteDetail  +   <--Here is where the 406 error code is returned in my 
error variable
INTO vQPart# INDICATOR vInd1, vLength INDICATOR  vInd2, vUMMult INDICATOR  
vInd3

Dan Goldberg



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 10:11 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman

[cid:image001.jpg@01D2EFF2.8B5CE210]<http://www.qmiusa.com/>

Stuart Hellman

Software Designer

Email:

  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:

  800-446-2500

International:

  01 630-529-7111

Extension:

  1029


www.qmiusa.com<http://www.qmiusa.com>




.


This email may contain material that is confidential, privileged and/or 
attorney work product for the s

RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-28 Thread Stuart Hellman
Buddy,

Thanks for the idea.

Walking thru the code once again, I noticed a couple of thing. First, the 
second and third variables in the cursor were not defined in the form anywhere. 
Second, the second variable (length) had a null value. Went back, defined the 
variables and stored a 0 (zero) if the field had no length (such as a motor).  
Nope, that wasn't the problem. Still getting the same results on the FETCH.

The environment is version 9.5 and I'm trying to convert this application from 
DOS to Windows.  I know these two environments are different, just wondering if 
I've forgotten to do something in my conversion process.

Stu Hellman



Stuart Hellman
Software Designer

Email:shell...@qmiusa.com
Toll Free: 800-446-2500
International: 01 630-529-7111
Extension: 1029

www.qmiusa.com

--
The information transmitted, including attachments, is intended only for the 
person(s) or entity to which it is addressed and may contain confidential 
and/or privileged material.  Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by persons or 
entities other than the intended recipient is prohibited.  If you received this 
in error, please contact the sender and destroy any copies of this information.

-Original Message-
From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Buddy Walker
Sent: Tuesday, June 27, 2017 12:44 PM
To: rbase-l@googlegroups.com
Subject: Re: [RBASE-L] - Peculiar Cursor Behavior

I would try this. Right before you open the cursor put in return. Now at the R 
prompt look at your  vWhere and try manually typing the vWhere with the browse. 
Maybe that will tell you what is happening.

Buddy

Sent from my iPhone

> On Jun 27, 2017, at 1:11 PM, Stuart Hellman <shell...@qmiusa.com> wrote:
>
> ENDIF

--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-28 Thread Stuart Hellman
Dan,

Thanks for the suggestion.

I did try your idea. I defined the indicators setting them to an initial value 
of -9 so I would know that those values changed.  Unfortunately, the FETCH  
command didn’t change the indicator values.

Stu Hellman

From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Dan Goldberg
Sent: Tuesday, June 27, 2017 12:27 PM
To: rbase-l@googlegroups.com
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Shouldn’t you have Indicator in your fetch command? I think the variables that 
hold the indicators should be different as well.


FETCH QteDetail  +   <--Here is where the 406 error code is returned in my 
error variable
INTO vQPart# INDICATOR vInd1, vLength INDICATOR  vInd2, vUMMult INDICATOR  
vInd3

Dan Goldberg



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 10:11 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman

[cid:image001.jpg@01D2EFEA.F9FA1E70]<http://www.qmiusa.com/>

Stuart Hellman

Software Designer

Email:

  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:

  800-446-2500

International:

  01 630-529-7111

Extension:

  1029


www.qmiusa.com<http://www.qmiusa.com>




.


This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and 

RE: [RBASE-L] - Peculiar Cursor Behavior

2017-06-27 Thread Stuart Hellman
There are different sets of tables used for different processes, so that is why 
the WHERE clause is a variable

  SET VAR vTable = 'QuoteDetail'
  SET VAR vWhere = ('WHERE Quote# = .vQuote# AND Window = .vWindow ')
  SET VAR vWhere = (.vWhere & 'AND CostType = .vPrimAlt')

SET VAR vWhere = +
(.vWhere & 'AND T2.SnapShotID = .vSnapShotID AND T1.MasterPart# = 
T2.MasterPart#')

BROWSE T1.MasterPart#, length, ummult FROM  T1, snappartmast T2 

DECLARE QteDetail CURSOR +
FOR SELECT T1.MasterPart#, T1.Length, T2.UMMult +
FROM  T1, SnapPartMast T2 

OPEN QteDetail

  FETCH QteDetail  +   <--Here is where the 406 error code is returned in 
my error variable
INTO vQPart# vInd, vLength vInd, vUMMult vInd
   IF SQLCODE = 100 THEN
   GOTO EndLoop
   ENDIF



From: rbase-l@googlegroups.com [mailto:rbase-l@googlegroups.com] On Behalf Of 
Buddy Walker
Sent: Tuesday, June 27, 2017 9:28 AM
To: rbase-l@googlegroups.com
Subject: RE: [RBASE-L] - Peculiar Cursor Behavior

Stuart
  Is it possible for you to show the complete browse and declare statements.

Buddy

From: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com> 
[mailto:rbase-l@googlegroups.com] On Behalf Of Stuart Hellman
Sent: Tuesday, June 27, 2017 8:51 AM
To: rbase-l@googlegroups.com<mailto:rbase-l@googlegroups.com>
Subject: [RBASE-L] - Peculiar Cursor Behavior

Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman

[cid:image001.jpg@01D2EF3E.76220EC0]<http://www.qmiusa.com/>

Stuart Hellman

Software Designer

Email:

  shell...@qmiusa.com<mailto:shell...@qmiusa.com>

Toll Free:

  800-446-2500

International:

  01 630-529-7111

Extension:

  1029


www.qmiusa.com<http://www.qmiusa.com>




.


This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
rbase-l+unsubscr...@googlegroups.com<mailto:rbase-l+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[RBASE-L] - Peculiar Cursor Behavior

2017-06-27 Thread Stuart Hellman
Need some expert advice on a cursor problem I’m having.

The situation is a large form in which is using about 10, one at a time. 
Nothing “exotic” is going on with the cursor in question. All of them work 
except one. Data is being retrieved from 2 tables. The cursor is dropped, 
declared, opened and then the data is to be fetched. This is the point where 
things go south.

The SQLCode being returned is ‘100’ and the Error Variable value returned is 
‘406’, which means End-Of-Data. In trying to determine the cause, a BROWSE was 
placed before the FETCH having converted the DECLARE statement. The three rows 
expected are displayed. Put a SELECT after, again converting the DECLARE 
statement plus adding a LIMIT = 1 clause. No problems.

Two very simple questions here:
1: Why is R:Base returning the End-Of-Data condition when the SELECT clause is 
correct?
2: What needs to be done to fix the situation?

Thank you in advance for your  help.


Stu Hellman



[cid:imagebb0774.JPG@00a77a1c.43b3f594]<http://www.qmiusa.com/>

Stuart Hellman
Software Designer
Email:shell...@qmiusa.com<mailto:shell...@qmiusa.com>
Toll Free:800-446-2500
International:01 630-529-7111
Extension:1029

www.qmiusa.com<http://www.qmiusa.com>




.

This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

-- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[RBASE-L] - DB TreeView - trying to highlight nodes

2017-02-03 Thread Stuart Hellman
I’ve been racking my brain over this one for a while. Would appreciate any and 
all help.

Using a DB TreeView control, I am trying to highlight/position a specific node 
within the tree. I know my logic is good that gets me the node ID that I want. 
However when I refresh the table/control, the incorrect text is highlighted.

Here’s what is happening:
Level 1   <-- click here
Level 2
Level 3
Level 2
Level 3 <-- highlight here (know the node ID)

I select “Level 1” in the control. I determine the node ID of Level 3 and want 
that node to be highlighted. I’ve used the FINDNODE property, but due redundant 
text, the first occurrence of the text is highlighted. The other idea attempted 
is to use the FINDPATHNODE property. The path name passed to the property is 
correct, but the last item that I selected (in this case “Level 1”)  is 
highlighted not the “level 3” node.

Probably missing something, just don’t know what.

Thanks in advance for your advice.



[cid:image94d946.JPG@a2c51fa3.48894fad]<http://www.qmiusa.com/>

Stuart Hellman
Software Designer
Email:shell...@qmiusa.com<mailto:shell...@qmiusa.com>
Toll Free:800-446-2500
International:01 630-529-7111
Extension:1029

www.qmiusa.com<http://www.qmiusa.com>




.

This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

-- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[RBASE-L] - Determining action on a click

2016-09-20 Thread Stuart Hellman
I am using a DB tree view in my processing. When a node in the view is clicked, 
sometimes the “On Click” event launched and sometimes the tree collapses 
without the “On Click” event executing. When the tree collapses, clicking on 
the node again executes the “On Click” event.

Is there a way to know when clicking on a tree node whether the “On Click” 
event or collapse action is going to happen? I always want the “On Click” event 
launched.

Thanks,
Stu Hellman




[cid:image939c44.JPG@cd8b2697.4d94f210]<http://www.qmiusa.com/>

Stuart Hellman
Software Designer
Email:shell...@qmiusa.com<mailto:shell...@qmiusa.com>
Toll Free:800-446-2500
International:01 630-529-7111
Extension:1029

www.qmiusa.com<http://www.qmiusa.com>




.

This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

-- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[RBASE-L] - Using views with a DB tree view

2016-07-25 Thread Stuart Hellman
I’ve created a view which is a union of other views that contains a portion of 
my original table. I can display the view, but when I click on a node in the DB 
Tree View, it’s as if nothing is selected. The values of my variables which 
contain the IDs of the parent and child nodes are not changed.

In testing I’ve tried including all the views in the union, the original table 
in which the views were created, using the view as the main table and as a 
slave table. What am I missing???

Thanks,

Stu Hellman




[cid:image5e9af0.JPG@901033e1.4c98eea3]<http://www.qmiusa.com/>

Stuart Hellman
Software Designer
Email:shell...@qmiusa.com<mailto:shell...@qmiusa.com>
Toll Free:800-446-2500
International:01 630-529-7111
Extension:1029

www.qmiusa.com<http://www.qmiusa.com>




.

This email may contain material that is confidential, privileged and/or 
attorney work product for the sole use of the intended recipient. Any review, 
reliance or distribution by others or forwarding without express permission is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies

-- 
You received this message because you are subscribed to the Google Groups 
"RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbase-l+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.