One more reason why progress should die

The purpose of this adventure was to move data from the MtlQueue records to the PartTran records at Issue or Return. In this case specifically to capture the create date and time of the MtlQueue record so that we can compare the create date/time of the queue record against the create date/time of the PartTran for delivery and pickup time reporting. Never thought we would get it with a crazy hex string like that!



Joshua Giese

CTO

920.437.6400 Ext. 337

Site ID: 27450-E905700B2-SQL64

----- Original Message -----

From: "Jose Gomez" <jose@...>
To: "Vantage" <vantage@yahoogroups.com>
Sent: Friday, June 14, 2013 10:18:22 AM
Subject: Re: [Vantage] One more reason why progress should die

Its SQL
Progress -> ODBC -> SQL


*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*


On Fri, Jun 14, 2013 at 11:11 AM, Chad Villa <chad.villa@...> wrote:

> **
>
>
> Jose,
>
> Was that system using a dataserver to a SQL db or was it an actual Progress
> database?
> I didn't think it was possible to overwrite a ROWID with what you saw. I'd
> be 'impressed' if Epicor managed that.
>
> Thanks,
>
> Chad
>
>
> On Fri, Jun 14, 2013 at 9:48 AM, Jose Gomez <jose@...> wrote:
>
> > Yeah i think its just progress being progress they do use a integer
> REC_ID
> > but the actual ROWID() that comes back is that hex string where clause
> > nightmare.
> >
> >
> > *Jose C Gomez*
> > *Software Engineer*
> > *
> > *
> > *
> > *T: 904.469.1524 mobile
> > E: jose@...
> > http://www.josecgomez.com
> > <http://www.linkedin.com/in/josecgomez> <
> > http://www.facebook.com/josegomez>
> > <http://www.google.com/profiles/jose.gomez> <
> > http://www.twitter.com/joc85>
> > <http://www.josecgomez.com/professional-resume/>
> > <http://www.josecgomez.com/feed/>
> > <http://www.usdoingstuff.com>
> >
> > *Quis custodiet ipsos custodes?*
> >
> >
> > On Fri, Jun 14, 2013 at 10:47 AM, Vic Drecchio
> > <vic.drecchio@...>wrote:
> >
> > > **
>
> > >
> > >
> > > Maybe you're right... That just seems like an unbelievable
> > limitation/PITA
> > > of a db server.
> > >
> > > Why not use a sequential integer?
> > >
> > > ...smh....
> > >
> > >
> > > -----Original Message-----
> > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> Behalf
> > > Of
> > > Jose Gomez
> > > Sent: Friday, June 14, 2013 10:35 AM
> > > To: Vantage
> > > Subject: Re: [Vantage] One more reason why progress should die
> > >
> > > So development made the row ids be that? I thoguht ROWID and TO-ROWID
> > was a
> > > Progress Function?
> > >
> > > *Jose C Gomez*
> > > *Software Engineer*
> > > *
> > > *
> > > *
> > > *T: 904.469.1524 mobile
> > > E: jose@...
> > > http://www.josecgomez.com
> > > <http://www.linkedin.com/in/josecgomez> <
> > http://www.facebook.com/josegomez
> > > >
> > > <http://www.google.com/profiles/jose.gomez> <
> > http://www.twitter.com/joc85>
> > > <http://www.josecgomez.com/professional-resume/>
> > > <http://www.josecgomez.com/feed/>
> > > <http://www.usdoingstuff.com>
> > >
> > > *Quis custodiet ipsos custodes?*
> > >
> > > On Fri, Jun 14, 2013 at 10:31 AM, Vic Drecchio
> > > <vic.drecchio@...>wrote:
> > >
> > > > **
> > >
> > > >
> > > >
> > > > That's the best subject line I've seen in a while. I second that. But
> > > > in Progress' defense, this is a development issue. This could be done
> > > > in SQL, Oracle or dBase III+.
> > > >
> > > > Just like the stupid ~ separating Sales Rep IDs.
> > > >
> > > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> > > > Behalf Of Jose Gomez
> > > > Sent: Friday, June 14, 2013 10:10 AM
> > > > To: Vantage
> > > > Subject: [Vantage] One more reason why progress should die
> > > >
> > > >
> > > > Working on a Customization we needed to get a hold of the MTL Queue.
> > > > In the trace there is
> > > > MtlQueueRowID=
> > > >
> > > >
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > > > 000058
> > > > 0008fffb00000000000000000000000000007b9729292000
> > > >
> > > > Which looking at the DB doesn't match anything in the record. Bummed
> > > > out we tried to translate the RowID from Hex to ASCI. Which some how
> > > > worked and we got
> > > >
> > > > ?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?
> > > >
> > > > So we assumed that ???X??????? was the actual REC_ID but it was a HEX
> > > > number not a Hex String. So after more poking around we got the
> REC_ID
> > > > 07b97
> > > > which translated to 31653 which was the MTL Queue we needed. Excited
> > > > we wrote some ABL to Parse that bohemoth and end up with the Mtl
> Queue
> > > > ID so that we could do some other stuff.
> > > >
> > > > When running a query such as
> > > > FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
> > > > END.
> > > >
> > > > The results were not appearing and out of curiosity I decided to
> > > > display the RowID of any MtlQueue
> > > >
> > > > FOR FIRST MtlQueue:
> > > > DISPLAY STRING(ROWID(mtlQueue)).
> > > > END.t
> > > >
> > > > To my surprise it returned
> > > >
> > > >
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > > > 000058
> > > > 0008fffb00000000000000000000000000007ba529292000
> > > >
> > > > Which is an identical string to the original one I parsed... So
> ladies
> > > > and gentlemen apparently Progress indexes and stores their data with
> a
> > > > WHERECLAUSE AS THER FREAKING RECORD ID.
> > > >
> > > > *FACE PALM*
> > > >
> > > > *Jose C Gomez*
> > > > *Software Engineer*
> > > > *
> > > > *
> > > > *
> > > > *T: 904.469.1524 mobile
> > > > E: jose@... <mailto:jose%40josecgomez.com>
> > > > http://www.josecgomez.com <http://www.linkedin.com/in/josecgomez>
> > > > <http://www.facebook.com/josegomez
> > > > >
> > > > <http://www.google.com/profiles/jose.gomez>
> > > > <http://www.twitter.com/joc85>
> > > > <http://www.josecgomez.com/professional-resume/>
> > > > <http://www.josecgomez.com/feed/>
> > > > <http://www.usdoingstuff.com>
> > > >
> > > > *Quis custodiet ipsos custodes?*
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > >
> > > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > > ------------------------------------
> > >
> > >
> > > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> > have
> > > already linked your email address to a yahoo id to enable access. )
> > > (1) To access the Files Section of our Yahoo!Group for Report Builder
> and
> > > Crystal Reports and other 'goodies', please goto:
> > > http://groups.yahoo.com/group/vantage/files/.
> > > (2) To search through old msg's goto:
> > > http://groups.yahoo.com/group/vantage/messages
> > > (3) To view links to Vendors that provide Vantage services goto:
> > > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> > have already linked your email address to a yahoo id to enable access. )
> > (1) To access the Files Section of our Yahoo!Group for Report Builder and
> > Crystal Reports and other 'goodies', please goto:
> > http://groups.yahoo.com/group/vantage/files/.
> > (2) To search through old msg's goto:
> > http://groups.yahoo.com/group/vantage/messages
> > (3) To view links to Vendors that provide Vantage services goto:
> > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and Crystal Reports and other 'goodies', please goto: http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto: http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto: http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links






[Non-text portions of this message have been removed]
Working on a Customization we needed to get a hold of the MTL Queue.
In the trace there is
MtlQueueRowID= 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d20000000580008fffb00000000000000000000000000007b9729292000

Which looking at the DB doesn't match anything in the record. Bummed out we
tried to translate the RowID from Hex to ASCI. Which some how worked and we
got

?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?

So we assumed that ???X??????? was the actual REC_ID but it was a HEX
number not a Hex String. So after more poking around we got the REC_ID 07b97
which translated to 31653 which was the MTL Queue we needed. Excited we
wrote some ABL to Parse that bohemoth and end up with the Mtl Queue ID so
that we could do some other stuff.


When running a query such as
FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
END.

The results were not appearing and out of curiosity I decided to display
the RowID of any MtlQueue

FOR FIRST MtlQueue:
DISPLAY STRING(ROWID(mtlQueue)).
END.t


To my surprise it returned
0x003d0baf00010000574845524520282850524f47524553535f5245434944203d20000000580008fffb00000000000000000000000000007ba529292000

Which is an identical string to the original one I parsed... So ladies and
gentlemen apparently Progress indexes and stores their data with a
WHERECLAUSE AS THER FREAKING RECORD ID.

*FACE PALM*


*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*


[Non-text portions of this message have been removed]
That's the best subject line I've seen in a while. I second that. But in
Progress' defense, this is a development issue. This could be done in SQL,
Oracle or dBase III+.



Just like the stupid ~ separating Sales Rep IDs.



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Jose Gomez
Sent: Friday, June 14, 2013 10:10 AM
To: Vantage
Subject: [Vantage] One more reason why progress should die





Working on a Customization we needed to get a hold of the MTL Queue.
In the trace there is
MtlQueueRowID=
0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000000058
0008fffb00000000000000000000000000007b9729292000

Which looking at the DB doesn't match anything in the record. Bummed out we
tried to translate the RowID from Hex to ASCI. Which some how worked and we
got

?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?

So we assumed that ???X??????? was the actual REC_ID but it was a HEX
number not a Hex String. So after more poking around we got the REC_ID 07b97
which translated to 31653 which was the MTL Queue we needed. Excited we
wrote some ABL to Parse that bohemoth and end up with the Mtl Queue ID so
that we could do some other stuff.

When running a query such as
FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
END.

The results were not appearing and out of curiosity I decided to display
the RowID of any MtlQueue

FOR FIRST MtlQueue:
DISPLAY STRING(ROWID(mtlQueue)).
END.t

To my surprise it returned
0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000000058
0008fffb00000000000000000000000000007ba529292000

Which is an identical string to the original one I parsed... So ladies and
gentlemen apparently Progress indexes and stores their data with a
WHERECLAUSE AS THER FREAKING RECORD ID.

*FACE PALM*

*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@... <mailto:jose%40josecgomez.com>
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]
So development made the row ids be that? I thoguht ROWID and TO-ROWID was a
Progress Function?


*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*


On Fri, Jun 14, 2013 at 10:31 AM, Vic Drecchio
<vic.drecchio@...>wrote:

> **
>
>
> That's the best subject line I've seen in a while. I second that. But in
> Progress' defense, this is a development issue. This could be done in SQL,
> Oracle or dBase III+.
>
> Just like the stupid ~ separating Sales Rep IDs.
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of
> Jose Gomez
> Sent: Friday, June 14, 2013 10:10 AM
> To: Vantage
> Subject: [Vantage] One more reason why progress should die
>
>
> Working on a Customization we needed to get a hold of the MTL Queue.
> In the trace there is
> MtlQueueRowID=
>
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000000058
> 0008fffb00000000000000000000000000007b9729292000
>
> Which looking at the DB doesn't match anything in the record. Bummed out we
> tried to translate the RowID from Hex to ASCI. Which some how worked and we
> got
>
> ?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?
>
> So we assumed that ???X??????? was the actual REC_ID but it was a HEX
> number not a Hex String. So after more poking around we got the REC_ID
> 07b97
> which translated to 31653 which was the MTL Queue we needed. Excited we
> wrote some ABL to Parse that bohemoth and end up with the Mtl Queue ID so
> that we could do some other stuff.
>
> When running a query such as
> FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
> END.
>
> The results were not appearing and out of curiosity I decided to display
> the RowID of any MtlQueue
>
> FOR FIRST MtlQueue:
> DISPLAY STRING(ROWID(mtlQueue)).
> END.t
>
> To my surprise it returned
>
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000000058
> 0008fffb00000000000000000000000000007ba529292000
>
> Which is an identical string to the original one I parsed... So ladies and
> gentlemen apparently Progress indexes and stores their data with a
> WHERECLAUSE AS THER FREAKING RECORD ID.
>
> *FACE PALM*
>
> *Jose C Gomez*
> *Software Engineer*
> *
> *
> *
> *T: 904.469.1524 mobile
> E: jose@... <mailto:jose%40josecgomez.com>
> http://www.josecgomez.com
> <http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez
> >
> <http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
> <http://www.josecgomez.com/professional-resume/>
> <http://www.josecgomez.com/feed/>
> <http://www.usdoingstuff.com>
>
> *Quis custodiet ipsos custodes?*
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]
Maybe you're right... That just seems like an unbelievable limitation/PITA
of a db server.

Why not use a sequential integer?

...smh....

-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Jose Gomez
Sent: Friday, June 14, 2013 10:35 AM
To: Vantage
Subject: Re: [Vantage] One more reason why progress should die

So development made the row ids be that? I thoguht ROWID and TO-ROWID was a
Progress Function?


*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*


On Fri, Jun 14, 2013 at 10:31 AM, Vic Drecchio
<vic.drecchio@...>wrote:

> **
>
>
> That's the best subject line I've seen in a while. I second that. But
> in Progress' defense, this is a development issue. This could be done
> in SQL, Oracle or dBase III+.
>
> Just like the stupid ~ separating Sales Rep IDs.
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> Behalf Of Jose Gomez
> Sent: Friday, June 14, 2013 10:10 AM
> To: Vantage
> Subject: [Vantage] One more reason why progress should die
>
>
> Working on a Customization we needed to get a hold of the MTL Queue.
> In the trace there is
> MtlQueueRowID=
>
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> 000058
> 0008fffb00000000000000000000000000007b9729292000
>
> Which looking at the DB doesn't match anything in the record. Bummed
> out we tried to translate the RowID from Hex to ASCI. Which some how
> worked and we got
>
> ?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?
>
> So we assumed that ???X??????? was the actual REC_ID but it was a HEX
> number not a Hex String. So after more poking around we got the REC_ID
> 07b97
> which translated to 31653 which was the MTL Queue we needed. Excited
> we wrote some ABL to Parse that bohemoth and end up with the Mtl Queue
> ID so that we could do some other stuff.
>
> When running a query such as
> FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
> END.
>
> The results were not appearing and out of curiosity I decided to
> display the RowID of any MtlQueue
>
> FOR FIRST MtlQueue:
> DISPLAY STRING(ROWID(mtlQueue)).
> END.t
>
> To my surprise it returned
>
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> 000058
> 0008fffb00000000000000000000000000007ba529292000
>
> Which is an identical string to the original one I parsed... So ladies
> and gentlemen apparently Progress indexes and stores their data with a
> WHERECLAUSE AS THER FREAKING RECORD ID.
>
> *FACE PALM*
>
> *Jose C Gomez*
> *Software Engineer*
> *
> *
> *
> *T: 904.469.1524 mobile
> E: jose@... <mailto:jose%40josecgomez.com>
> http://www.josecgomez.com <http://www.linkedin.com/in/josecgomez>
> <http://www.facebook.com/josegomez
> >
> <http://www.google.com/profiles/jose.gomez>
> <http://www.twitter.com/joc85>
> <http://www.josecgomez.com/professional-resume/>
> <http://www.josecgomez.com/feed/>
> <http://www.usdoingstuff.com>
>
> *Quis custodiet ipsos custodes?*
>
> [Non-text portions of this message have been removed]
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder and
Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
Yeah i think its just progress being progress they do use a integer REC_ID
but the actual ROWID() that comes back is that hex string where clause
nightmare.


*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*


On Fri, Jun 14, 2013 at 10:47 AM, Vic Drecchio
<vic.drecchio@...>wrote:

> **
>
>
> Maybe you're right... That just seems like an unbelievable limitation/PITA
> of a db server.
>
> Why not use a sequential integer?
>
> ...smh....
>
>
> -----Original Message-----
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of
> Jose Gomez
> Sent: Friday, June 14, 2013 10:35 AM
> To: Vantage
> Subject: Re: [Vantage] One more reason why progress should die
>
> So development made the row ids be that? I thoguht ROWID and TO-ROWID was a
> Progress Function?
>
> *Jose C Gomez*
> *Software Engineer*
> *
> *
> *
> *T: 904.469.1524 mobile
> E: jose@...
> http://www.josecgomez.com
> <http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez
> >
> <http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
> <http://www.josecgomez.com/professional-resume/>
> <http://www.josecgomez.com/feed/>
> <http://www.usdoingstuff.com>
>
> *Quis custodiet ipsos custodes?*
>
> On Fri, Jun 14, 2013 at 10:31 AM, Vic Drecchio
> <vic.drecchio@...>wrote:
>
> > **
>
> >
> >
> > That's the best subject line I've seen in a while. I second that. But
> > in Progress' defense, this is a development issue. This could be done
> > in SQL, Oracle or dBase III+.
> >
> > Just like the stupid ~ separating Sales Rep IDs.
> >
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> > Behalf Of Jose Gomez
> > Sent: Friday, June 14, 2013 10:10 AM
> > To: Vantage
> > Subject: [Vantage] One more reason why progress should die
> >
> >
> > Working on a Customization we needed to get a hold of the MTL Queue.
> > In the trace there is
> > MtlQueueRowID=
> >
> > 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > 000058
> > 0008fffb00000000000000000000000000007b9729292000
> >
> > Which looking at the DB doesn't match anything in the record. Bummed
> > out we tried to translate the RowID from Hex to ASCI. Which some how
> > worked and we got
> >
> > ?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?
> >
> > So we assumed that ???X??????? was the actual REC_ID but it was a HEX
> > number not a Hex String. So after more poking around we got the REC_ID
> > 07b97
> > which translated to 31653 which was the MTL Queue we needed. Excited
> > we wrote some ABL to Parse that bohemoth and end up with the Mtl Queue
> > ID so that we could do some other stuff.
> >
> > When running a query such as
> > FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
> > END.
> >
> > The results were not appearing and out of curiosity I decided to
> > display the RowID of any MtlQueue
> >
> > FOR FIRST MtlQueue:
> > DISPLAY STRING(ROWID(mtlQueue)).
> > END.t
> >
> > To my surprise it returned
> >
> > 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > 000058
> > 0008fffb00000000000000000000000000007ba529292000
> >
> > Which is an identical string to the original one I parsed... So ladies
> > and gentlemen apparently Progress indexes and stores their data with a
> > WHERECLAUSE AS THER FREAKING RECORD ID.
> >
> > *FACE PALM*
> >
> > *Jose C Gomez*
> > *Software Engineer*
> > *
> > *
> > *
> > *T: 904.469.1524 mobile
> > E: jose@... <mailto:jose%40josecgomez.com>
> > http://www.josecgomez.com <http://www.linkedin.com/in/josecgomez>
> > <http://www.facebook.com/josegomez
> > >
> > <http://www.google.com/profiles/jose.gomez>
> > <http://www.twitter.com/joc85>
> > <http://www.josecgomez.com/professional-resume/>
> > <http://www.josecgomez.com/feed/>
> > <http://www.usdoingstuff.com>
> >
> > *Quis custodiet ipsos custodes?*
> >
> > [Non-text portions of this message have been removed]
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
> ------------------------------------
>
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must have
> already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>


[Non-text portions of this message have been removed]
Jose,

Was that system using a dataserver to a SQL db or was it an actual Progress
database?
I didn't think it was possible to overwrite a ROWID with what you saw. I'd
be 'impressed' if Epicor managed that.

Thanks,

Chad



On Fri, Jun 14, 2013 at 9:48 AM, Jose Gomez <jose@...> wrote:

> Yeah i think its just progress being progress they do use a integer REC_ID
> but the actual ROWID() that comes back is that hex string where clause
> nightmare.
>
>
> *Jose C Gomez*
> *Software Engineer*
> *
> *
> *
> *T: 904.469.1524 mobile
> E: jose@...
> http://www.josecgomez.com
> <http://www.linkedin.com/in/josecgomez> <
> http://www.facebook.com/josegomez>
> <http://www.google.com/profiles/jose.gomez> <
> http://www.twitter.com/joc85>
> <http://www.josecgomez.com/professional-resume/>
> <http://www.josecgomez.com/feed/>
> <http://www.usdoingstuff.com>
>
> *Quis custodiet ipsos custodes?*
>
>
> On Fri, Jun 14, 2013 at 10:47 AM, Vic Drecchio
> <vic.drecchio@...>wrote:
>
> > **
> >
> >
> > Maybe you're right... That just seems like an unbelievable
> limitation/PITA
> > of a db server.
> >
> > Why not use a sequential integer?
> >
> > ...smh....
> >
> >
> > -----Original Message-----
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> > Of
> > Jose Gomez
> > Sent: Friday, June 14, 2013 10:35 AM
> > To: Vantage
> > Subject: Re: [Vantage] One more reason why progress should die
> >
> > So development made the row ids be that? I thoguht ROWID and TO-ROWID
> was a
> > Progress Function?
> >
> > *Jose C Gomez*
> > *Software Engineer*
> > *
> > *
> > *
> > *T: 904.469.1524 mobile
> > E: jose@...
> > http://www.josecgomez.com
> > <http://www.linkedin.com/in/josecgomez> <
> http://www.facebook.com/josegomez
> > >
> > <http://www.google.com/profiles/jose.gomez> <
> http://www.twitter.com/joc85>
> > <http://www.josecgomez.com/professional-resume/>
> > <http://www.josecgomez.com/feed/>
> > <http://www.usdoingstuff.com>
> >
> > *Quis custodiet ipsos custodes?*
> >
> > On Fri, Jun 14, 2013 at 10:31 AM, Vic Drecchio
> > <vic.drecchio@...>wrote:
> >
> > > **
> >
> > >
> > >
> > > That's the best subject line I've seen in a while. I second that. But
> > > in Progress' defense, this is a development issue. This could be done
> > > in SQL, Oracle or dBase III+.
> > >
> > > Just like the stupid ~ separating Sales Rep IDs.
> > >
> > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> > > Behalf Of Jose Gomez
> > > Sent: Friday, June 14, 2013 10:10 AM
> > > To: Vantage
> > > Subject: [Vantage] One more reason why progress should die
> > >
> > >
> > > Working on a Customization we needed to get a hold of the MTL Queue.
> > > In the trace there is
> > > MtlQueueRowID=
> > >
> > > 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > > 000058
> > > 0008fffb00000000000000000000000000007b9729292000
> > >
> > > Which looking at the DB doesn't match anything in the record. Bummed
> > > out we tried to translate the RowID from Hex to ASCI. Which some how
> > > worked and we got
> > >
> > > ?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?
> > >
> > > So we assumed that ???X??????? was the actual REC_ID but it was a HEX
> > > number not a Hex String. So after more poking around we got the REC_ID
> > > 07b97
> > > which translated to 31653 which was the MTL Queue we needed. Excited
> > > we wrote some ABL to Parse that bohemoth and end up with the Mtl Queue
> > > ID so that we could do some other stuff.
> > >
> > > When running a query such as
> > > FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
> > > END.
> > >
> > > The results were not appearing and out of curiosity I decided to
> > > display the RowID of any MtlQueue
> > >
> > > FOR FIRST MtlQueue:
> > > DISPLAY STRING(ROWID(mtlQueue)).
> > > END.t
> > >
> > > To my surprise it returned
> > >
> > > 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > > 000058
> > > 0008fffb00000000000000000000000000007ba529292000
> > >
> > > Which is an identical string to the original one I parsed... So ladies
> > > and gentlemen apparently Progress indexes and stores their data with a
> > > WHERECLAUSE AS THER FREAKING RECORD ID.
> > >
> > > *FACE PALM*
> > >
> > > *Jose C Gomez*
> > > *Software Engineer*
> > > *
> > > *
> > > *
> > > *T: 904.469.1524 mobile
> > > E: jose@... <mailto:jose%40josecgomez.com>
> > > http://www.josecgomez.com <http://www.linkedin.com/in/josecgomez>
> > > <http://www.facebook.com/josegomez
> > > >
> > > <http://www.google.com/profiles/jose.gomez>
> > > <http://www.twitter.com/joc85>
> > > <http://www.josecgomez.com/professional-resume/>
> > > <http://www.josecgomez.com/feed/>
> > > <http://www.usdoingstuff.com>
> > >
> > > *Quis custodiet ipsos custodes?*
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> > ------------------------------------
> >
> >
> > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have
> > already linked your email address to a yahoo id to enable access. )
> > (1) To access the Files Section of our Yahoo!Group for Report Builder and
> > Crystal Reports and other 'goodies', please goto:
> > http://groups.yahoo.com/group/vantage/files/.
> > (2) To search through old msg's goto:
> > http://groups.yahoo.com/group/vantage/messages
> > (3) To view links to Vendors that provide Vantage services goto:
> > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]
Its SQL
Progress -> ODBC -> SQL


*Jose C Gomez*
*Software Engineer*
*
*
*
*T: 904.469.1524 mobile
E: jose@...
http://www.josecgomez.com
<http://www.linkedin.com/in/josecgomez> <http://www.facebook.com/josegomez>
<http://www.google.com/profiles/jose.gomez> <http://www.twitter.com/joc85>
<http://www.josecgomez.com/professional-resume/>
<http://www.josecgomez.com/feed/>
<http://www.usdoingstuff.com>

*Quis custodiet ipsos custodes?*


On Fri, Jun 14, 2013 at 11:11 AM, Chad Villa <chad.villa@...> wrote:

> **
>
>
> Jose,
>
> Was that system using a dataserver to a SQL db or was it an actual Progress
> database?
> I didn't think it was possible to overwrite a ROWID with what you saw. I'd
> be 'impressed' if Epicor managed that.
>
> Thanks,
>
> Chad
>
>
> On Fri, Jun 14, 2013 at 9:48 AM, Jose Gomez <jose@...> wrote:
>
> > Yeah i think its just progress being progress they do use a integer
> REC_ID
> > but the actual ROWID() that comes back is that hex string where clause
> > nightmare.
> >
> >
> > *Jose C Gomez*
> > *Software Engineer*
> > *
> > *
> > *
> > *T: 904.469.1524 mobile
> > E: jose@...
> > http://www.josecgomez.com
> > <http://www.linkedin.com/in/josecgomez> <
> > http://www.facebook.com/josegomez>
> > <http://www.google.com/profiles/jose.gomez> <
> > http://www.twitter.com/joc85>
> > <http://www.josecgomez.com/professional-resume/>
> > <http://www.josecgomez.com/feed/>
> > <http://www.usdoingstuff.com>
> >
> > *Quis custodiet ipsos custodes?*
> >
> >
> > On Fri, Jun 14, 2013 at 10:47 AM, Vic Drecchio
> > <vic.drecchio@...>wrote:
> >
> > > **
>
> > >
> > >
> > > Maybe you're right... That just seems like an unbelievable
> > limitation/PITA
> > > of a db server.
> > >
> > > Why not use a sequential integer?
> > >
> > > ...smh....
> > >
> > >
> > > -----Original Message-----
> > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> Behalf
> > > Of
> > > Jose Gomez
> > > Sent: Friday, June 14, 2013 10:35 AM
> > > To: Vantage
> > > Subject: Re: [Vantage] One more reason why progress should die
> > >
> > > So development made the row ids be that? I thoguht ROWID and TO-ROWID
> > was a
> > > Progress Function?
> > >
> > > *Jose C Gomez*
> > > *Software Engineer*
> > > *
> > > *
> > > *
> > > *T: 904.469.1524 mobile
> > > E: jose@...
> > > http://www.josecgomez.com
> > > <http://www.linkedin.com/in/josecgomez> <
> > http://www.facebook.com/josegomez
> > > >
> > > <http://www.google.com/profiles/jose.gomez> <
> > http://www.twitter.com/joc85>
> > > <http://www.josecgomez.com/professional-resume/>
> > > <http://www.josecgomez.com/feed/>
> > > <http://www.usdoingstuff.com>
> > >
> > > *Quis custodiet ipsos custodes?*
> > >
> > > On Fri, Jun 14, 2013 at 10:31 AM, Vic Drecchio
> > > <vic.drecchio@...>wrote:
> > >
> > > > **
> > >
> > > >
> > > >
> > > > That's the best subject line I've seen in a while. I second that. But
> > > > in Progress' defense, this is a development issue. This could be done
> > > > in SQL, Oracle or dBase III+.
> > > >
> > > > Just like the stupid ~ separating Sales Rep IDs.
> > > >
> > > > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On
> > > > Behalf Of Jose Gomez
> > > > Sent: Friday, June 14, 2013 10:10 AM
> > > > To: Vantage
> > > > Subject: [Vantage] One more reason why progress should die
> > > >
> > > >
> > > > Working on a Customization we needed to get a hold of the MTL Queue.
> > > > In the trace there is
> > > > MtlQueueRowID=
> > > >
> > > >
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > > > 000058
> > > > 0008fffb00000000000000000000000000007b9729292000
> > > >
> > > > Which looking at the DB doesn't match anything in the record. Bummed
> > > > out we tried to translate the RowID from Hex to ASCI. Which some how
> > > > worked and we got
> > > >
> > > > ?=??????WHERE ((PROGRESS_RECID = ???X??????????????????{?)) ?
> > > >
> > > > So we assumed that ???X??????? was the actual REC_ID but it was a HEX
> > > > number not a Hex String. So after more poking around we got the
> REC_ID
> > > > 07b97
> > > > which translated to 31653 which was the MTL Queue we needed. Excited
> > > > we wrote some ABL to Parse that bohemoth and end up with the Mtl
> Queue
> > > > ID so that we could do some other stuff.
> > > >
> > > > When running a query such as
> > > > FOR EACH MtlQueue WHERE ROWID(MtlQueue)=TO-ROWID(MyParsedString):
> > > > END.
> > > >
> > > > The results were not appearing and out of curiosity I decided to
> > > > display the RowID of any MtlQueue
> > > >
> > > > FOR FIRST MtlQueue:
> > > > DISPLAY STRING(ROWID(mtlQueue)).
> > > > END.t
> > > >
> > > > To my surprise it returned
> > > >
> > > >
> 0x003d0baf00010000574845524520282850524f47524553535f5245434944203d2000
> > > > 000058
> > > > 0008fffb00000000000000000000000000007ba529292000
> > > >
> > > > Which is an identical string to the original one I parsed... So
> ladies
> > > > and gentlemen apparently Progress indexes and stores their data with
> a
> > > > WHERECLAUSE AS THER FREAKING RECORD ID.
> > > >
> > > > *FACE PALM*
> > > >
> > > > *Jose C Gomez*
> > > > *Software Engineer*
> > > > *
> > > > *
> > > > *
> > > > *T: 904.469.1524 mobile
> > > > E: jose@... <mailto:jose%40josecgomez.com>
> > > > http://www.josecgomez.com <http://www.linkedin.com/in/josecgomez>
> > > > <http://www.facebook.com/josegomez
> > > > >
> > > > <http://www.google.com/profiles/jose.gomez>
> > > > <http://www.twitter.com/joc85>
> > > > <http://www.josecgomez.com/professional-resume/>
> > > > <http://www.josecgomez.com/feed/>
> > > > <http://www.usdoingstuff.com>
> > > >
> > > > *Quis custodiet ipsos custodes?*
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > > >
> > > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > > ------------------------------------
> > >
> > >
> > > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> > have
> > > already linked your email address to a yahoo id to enable access. )
> > > (1) To access the Files Section of our Yahoo!Group for Report Builder
> and
> > > Crystal Reports and other 'goodies', please goto:
> > > http://groups.yahoo.com/group/vantage/files/.
> > > (2) To search through old msg's goto:
> > > http://groups.yahoo.com/group/vantage/messages
> > > (3) To view links to Vendors that provide Vantage services goto:
> > > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> > have already linked your email address to a yahoo id to enable access. )
> > (1) To access the Files Section of our Yahoo!Group for Report Builder and
> > Crystal Reports and other 'goodies', please goto:
> > http://groups.yahoo.com/group/vantage/files/.
> > (2) To search through old msg's goto:
> > http://groups.yahoo.com/group/vantage/messages
> > (3) To view links to Vendors that provide Vantage services goto:
> > http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]