We have a temp-table sdo which we are populating in initializeObject of the SDO. This works fine client server. If we run it against the appserver we don't get any records displaying in the viewer or browser.
If we move the population of the temp-table to the MAIN procedure, it works. For various reasons though, we need to run the population of the temp-table in initializeObject.
Why is this? Where does the temp-table get copied to the rowObject table and can we force this to happen? Does anyone have any ideas why this works client/server, i.e. the rowObject temp-table is being populated?
Thanks
Robert
Robert,
How are you communicating with the appserver?
It may be that your connection is failing and therefore not returning any
records?
Ashley.
Ashley Tyler B.Eng (Hons), Software Developer
Information Technology Department
Roger Bullivant Limited
Tel : +44 (0) 1283 525002
Fax :+44 (0) 1283 527923
e-mail : ashley.tyler@roger-bullivant.co.uk
http://www.roger-bullivant.co.uk
Address : Walton Road, Drakelow, Burton-On-Trent, Staffs, DE15 9UA
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Ashley
Thanks for your response.
We aren't having any other problems with the appserver, everything else
works when we run against the appserver. Also there are no errors in the
log file.
Thanks,
Robert
- Original Message -
From: To: Sent: Monday, January 06, 2003 2:07 PM
Subject: Re: Populating temp table SDO's
Robert,
How are you communicating with the appserver?
It may be that your connection is failing and therefore not returning any
records?
Ashley.
Ashley Tyler B.Eng (Hons), Software Developer
Information Technology Department
Roger Bullivant Limited
Tel : +44 (0) 1283 525002
Fax :+44 (0) 1283 527923
e-mail : ashley.tyler@roger-bullivant.co.uk
http://www.roger-bullivant.co.uk
Address : Walton Road, Drakelow, Burton-On-Trent, Staffs, DE15 9UA
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
"robert.pooley" wrote:
We have a temp-table sdo which we are populating in
initializeObject of the SDO. This works fine client
server. If we run it against the appserver we don't
get any records displaying in the viewer or browser.
If we move the population of the temp-table to the
MAIN procedure, it works. For various reasons
though, we need to run the population of the
temp-table in initializeObject.
Why is this? Where does the temp-table get copied
to the rowObject table and can we force this to
happen? Does anyone have any ideas why this works
client/server, i.e. the rowObject temp-table is
being populated?
Robert,
A couple of things to check:
- Make sure you are populating the temp-table
before the SUPER run in initializeObject.
- If you can't do that for some reason, turn the
openOnInit property off for the SDO and you may have
to do the population and run queryOpen yourself.
Rick
=====
Rick Terrell
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Rick,
I was very surprised when I heard that you had been laid-off. How are
you doing? Are you about to get any work? What's your phone number?
Ross
Rick Terrell wrote:
> "robert.pooley" wrote:
>
>>We have a temp-table sdo which we are populating in
>>initializeObject of the SDO. This works fine client
>>server. If we run it against the appserver we don't
>>get any records displaying in the viewer or browser.
>>
>>If we move the population of the temp-table to the
>>MAIN procedure, it works. For various reasons
>>though, we need to run the population of the
>>temp-table in initializeObject.
>>
>>Why is this? Where does the temp-table get copied
>>to the rowObject table and can we force this to
>>happen? Does anyone have any ideas why this works
>>client/server, i.e. the rowObject temp-table is
>>being populated?
>>
>>
>
>Robert,
A couple of things to check:
- Make sure you are populating the temp-table
>before the SUPER run in initializeObject.
- If you can't do that for some reason, turn the
>openOnInit property off for the SDO and you may have
>to do the population and run queryOpen yourself.
>
>Rick
>
>=====
>Rick Terrell
>
>__________________________________________________
>Do you Yahoo!?
>Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
>http://mailplus.yahoo.com
>
>
>To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
>For additional commands, e-mail: dev-help@icf.possenet.org
>
>
Ross Hunter wrote:
Rick,
I was very surprised when I heard that you had been laid-off. How are you
doing? Are you about to get any work? What's your phone number?
Ross
>
You sure you wanted to broadcast this to every Dynamics user in the world?
--
Tom Barringer "They that can give up essential liberty
Staff Consultant to obtain a little temporary safety
Empowerment Center NA deserve neither liberty nor safety."
Progress Software -- Benjamin Franklin
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
I also have an issue with temp-tables across appserver, so I hope that this
thread isn't dead!
Tom Greenwood
President, DEGAMA Systems Inc.
http://www.degama.com
416-493-0059 x107
-Original Message-
Sent: Monday, January 06, 2003 7:33 AM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Ashley
Thanks for your response.
We aren't having any other problems with the appserver, everything else
works when we run against the appserver. Also there are no errors in the
log file.
Thanks,
Robert
- Original Message -
From: To: Sent: Monday, January 06, 2003 2:07 PM
Subject: Re: Populating temp table SDO's
Robert,
How are you communicating with the appserver?
It may be that your connection is failing and therefore not
returning any
records?
Ashley.
Ashley Tyler B.Eng (Hons), Software Developer
Information Technology Department
Roger Bullivant Limited
Tel : +44 (0) 1283 525002
Fax :+44 (0) 1283 527923
e-mail : ashley.tyler@roger-bullivant.co.uk
http://www.roger-bullivant.co.uk
Address : Walton Road, Drakelow, Burton-On-Trent, Staffs, DE15 9UA
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi,
I had a similar problem with TT SDOs and after some investigation realised that because, in an AppServer mode, the server-side SDO is started up and shut down on an as-needed basis, it will open its query against the TT, but there is no guarantee that there is any data in the SDO on the server - all the data is contained in the client-side SDO.
I worked around this by forcing the SDO to run client-side only (and I can't remember off the top of my head how I did this) and this worked fine. I just needed to make sure that the initial population of the TT took the fact that there might be an AppServer running into consideration, and all was fine.
I think that I set a property or something to force the SDO to run client only - I think there is a "ClientOnly" property that you can set against the SDO. I remember looking through constructObject in containr.p for clues. I can't guarantee that any of this is 100% correct though
HTH,
Peter
|-Original Message-
|Sent: Tuesday, January 14, 2003 8:57 PM
|To: dev@icf.possenet.org
|Subject: RE: Populating temp table SDO's
|
|
|I also have an issue with temp-tables across appserver, so I
|hope that this thread isn't dead!
|
|Tom Greenwood
|President, DEGAMA Systems Inc.
|http://www.degama.com
|416-493-0059 x107
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
What's your problem exactly?
Did you read the whitepaper on temp-table SDO's?
Remember that YOU have to populate the temp-table BEFORE any open-query is
issued and that you need the complete SDO on the client side.
HTH,
Wim
At 14:56 14/01/2003 -0500, Tom Greenwood wrote:
I also have an issue with temp-tables across appserver, so I hope that this
thread isn't dead!
Tom Greenwood
President, DEGAMA Systems Inc.
http://www.degama.com
416-493-0059 x107
-Original Message-
Sent: Monday, January 06, 2003 7:33 AM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Ashley
Thanks for your response.
We aren't having any other problems with the appserver, everything else
works when we run against the appserver. Also there are no errors in the
log file.
Thanks,
Robert
- Original Message -
From: To: Sent: Monday, January 06, 2003 2:07 PM
Subject: Re: Populating temp table SDO's
Robert,
How are you communicating with the appserver?
It may be that your connection is failing and therefore not
returning any
records?
Ashley.
Ashley Tyler B.Eng (Hons), Software Developer
Information Technology Department
Roger Bullivant Limited
Tel : +44 (0) 1283 525002
Fax :+44 (0) 1283 527923
e-mail : ashley.tyler@roger-bullivant.co.uk
http://www.roger-bullivant.co.uk
Address : Walton Road, Drakelow, Burton-On-Trent, Staffs, DE15 9UA
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
_________________________________________________
Ing. Wilhelmus van der Ham
WITS - Worldwide IT Solutions sas
di Wilhelmus van der Ham & C.
Italian partner for DWP: http://www.dynamicwebclient.info
via Motrassino, 2
10078 Venaria-Reale (TO) - Italy
Internet: http://www.wits.it
Telephone: +39-011-4527691
Mobile Phone: +39-335-6877283
Mobile Fax: +39-335-0-6877283
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Thanks for asking Wim...
We need to be able to rebuild the SDO's temp-table at various times
after the SDO has been intialized.
To do this we have a 'buildTemp' procedure in the SDO, with some
input parameters that control the database query used to populate
the temp-table.
The db-required code is 'wrapped' in preprocessors, and aflaunch.i
used to run the buildTemp internal procedure in the SDO server-side.
Then an openQuery is called from the client.
It works fine in client/server mode, but not in stateless appserver mode.
I'm pretty sure why this doesn't work - I just don't know (yet) how
to make it work...
So any suggestions you may have would be greatly appreciated.
TIA
Tom
-Original Message-
Sent: Wednesday, January 15, 2003 4:22 AM
To: dev@icf.possenet.org; dev@icf.possenet.org
Subject: RE: Populating temp table SDO's
What's your problem exactly?
Did you read the whitepaper on temp-table SDO's?
Remember that YOU have to populate the temp-table BEFORE any
open-query is
issued and that you need the complete SDO on the client side.
HTH,
Wim
At 14:56 14/01/2003 -0500, Tom Greenwood wrote:
I also have an issue with temp-tables across appserver, so I
hope that this
thread isn't dead!
Tom Greenwood
President, DEGAMA Systems Inc.
http://www.degama.com
416-493-0059 x107
-Original Message-
Sent: Monday, January 06, 2003 7:33 AM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Ashley
Thanks for your response.
We aren't having any other problems with the appserver,
everything else
works when we run against the appserver. Also there are no
errors in the
log file.
Thanks,
Robert
- Original Message -
From: To: Sent: Monday, January 06, 2003 2:07 PM
Subject: Re: Populating temp table SDO's
Robert,
How are you communicating with the appserver?
It may be that your connection is failing and therefore not
returning any
records?
Ashley.
Ashley Tyler B.Eng (Hons), Software Developer
Information Technology Department
Roger Bullivant Limited
Tel : +44 (0) 1283 525002
Fax :+44 (0) 1283 527923
e-mail : ashley.tyler@roger-bullivant.co.uk
http://www.roger-bullivant.co.uk
Address : Walton Road, Drakelow, Burton-On-Trent, Staffs, DE15 9UA
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
_________________________________________________
Ing. Wilhelmus van der Ham
WITS - Worldwide IT Solutions sas
di Wilhelmus van der Ham & C.
Italian partner for DWP: http://www.dynamicwebclient.info
via Motrassino, 2
10078 Venaria-Reale (TO) - Italy
Internet: http://www.wits.it
Telephone: +39-011-4527691
Mobile Phone: +39-335-6877283
Mobile Fax: +39-335-0-6877283
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Tom,
Peter is right, you have to run the SDO in full client mode to get it work
properly otherwise you risk to lose your temp-table or waste time rebuilding
the temp-table each time a server-side call is made. The attribute you have
to set (or should I say unset) is AppService - it should be blank, so the
SDO will be started on the client side only. That means both the SDO and the
LP cannot have database references; you'll get run-time errors otherwise.
Write a separate PLIP that has all the db required code and fire it on
request. That "buildTemp" procedure of yours should be placed in this extra
PLIP. Make a call to the buildTemp from initializeObject (before super) if
OpenOnInit is yes and you should be fine. Make a similar code whenever you
need to refresh the temp-table.
We have a few temp-table SDOs running fine over here, let me know if you
need more help.
SiL
-Original Message-
Sent: Thursday, 16 January 2003 03:13
To: dev@icf.possenet.org
Subject: RE: Populating temp table SDO's
Thanks for asking Wim...
We need to be able to rebuild the SDO's temp-table at various times
after the SDO has been intialized.
To do this we have a 'buildTemp' procedure in the SDO, with some
input parameters that control the database query used to populate
the temp-table.
The db-required code is 'wrapped' in preprocessors, and aflaunch.i
used to run the buildTemp internal procedure in the SDO server-side.
Then an openQuery is called from the client.
It works fine in client/server mode, but not in stateless appserver mode.
I'm pretty sure why this doesn't work - I just don't know (yet) how
to make it work...
So any suggestions you may have would be greatly appreciated.
TIA
Tom
-Original Message-
Sent: Wednesday, January 15, 2003 4:22 AM
To: dev@icf.possenet.org; dev@icf.possenet.org
Subject: RE: Populating temp table SDO's
What's your problem exactly?
Did you read the whitepaper on temp-table SDO's?
Remember that YOU have to populate the temp-table BEFORE any
open-query is
issued and that you need the complete SDO on the client side.
HTH,
Wim
At 14:56 14/01/2003 -0500, Tom Greenwood wrote:
I also have an issue with temp-tables across appserver, so I
hope that this
thread isn't dead!
Tom Greenwood
President, DEGAMA Systems Inc.
http://www.degama.com
416-493-0059 x107
-Original Message-
Sent: Monday, January 06, 2003 7:33 AM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Ashley
Thanks for your response.
We aren't having any other problems with the appserver,
everything else
works when we run against the appserver. Also there are no
errors in the
log file.
Thanks,
Robert
- Original Message -
From: To: Sent: Monday, January 06, 2003 2:07 PM
Subject: Re: Populating temp table SDO's
Robert,
How are you communicating with the appserver?
It may be that your connection is failing and therefore not
returning any
records?
Ashley.
Ashley Tyler B.Eng (Hons), Software Developer
Information Technology Department
Roger Bullivant Limited
Tel : +44 (0) 1283 525002
Fax :+44 (0) 1283 527923
e-mail : ashley.tyler@roger-bullivant.co.uk
http://www.roger-bullivant.co.uk
Address : Walton Road, Drakelow, Burton-On-Trent, Staffs, DE15 9UA
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
_________________________________________________
Ing. Wilhelmus van der Ham
WITS - Worldwide IT Solutions sas
di Wilhelmus van der Ham & C.
Italian partner for DWP: http://www.dynamicwebclient.info
via Motrassino, 2
10078 Venaria-Reale (TO) - Italy
Internet: http://www.wits.it
Telephone: +39-011-4527691
Mobile Phone: +39-335-6877283
Mobile Fax: +39-335-0-6877283
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Simion,
Thanks for getting back to me. That sounds reasonable enough, except...
I have a bit of an issue with one SDO that has a temp-table joined
one-to-one with a live database table -- the add, change, and delete
functionality works perfectly against the live db table, even accross
the AppServer boundary! It sounds like going client-only will mean that
I'll have to handle all the stuff in PLiPs, not just the population of
the temp-table. I'm I mistaken here?
I suspect in this case, there is a way to retain the full SDO functionality
(even if it was never intended to be used this way) and still be able to
initiate rebuilds of the temp-table from the client side... In this
particular
case the rowobject record only contains data from the live db table, and the
temp-table is used as a mechanism to efficiently extract record sets from a
table with a large number of records, in a way that would not be possible by
manipulating the query string of the table itself. It works really well.
What do you think?
-Tom
=========================
Date: Thu, 16 Jan 2003 09:51:06 +1100
From: Simion Legian
Content-type: text/plain; charset=us-ascii
Subject: RE: Populating temp table SDO's
Hi Tom,
Peter is right, you have to run the SDO in full client mode to get it work
properly otherwise you risk to lose your temp-table or waste time rebuilding
the temp-table each time a server-side call is made. The attribute you have
to set (or should I say unset) is AppService - it should be blank, so the
SDO will be started on the client side only. That means both the SDO and the
LP cannot have database references; you'll get run-time errors otherwise.
Write a separate PLIP that has all the db required code and fire it on
request. That "buildTemp" procedure of yours should be placed in this extra
PLIP. Make a call to the buildTemp from initializeObject (before super) if
OpenOnInit is yes and you should be fine. Make a similar code whenever you
need to refresh the temp-table.
We have a few temp-table SDOs running fine over here, let me know if you
need more help.
SiL
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Tom,
Once you start rebuilding the temp-table on the client side you end up
changing the rowids that are associated with them in the rowobject
table. What you'll end up with if you don't refresh the entire query is
the rowids stored in the rowobject table won't match the real rowids of
the temp-table that exists in memory after you rebuild only the temp-table.
You'll end up in an inconsistent state with rowids that don't exist
because your temp-table has a completely different set of rowids.
Unless someone has a more creative idea, you'll have to bite the bullet
and refresh the whole query from the server.
I have tried doing something just like this in the past and it caused
problems with repositioning when doing batches.
mattB
Tom Greenwood wrote:
>Hi Simion,
>
>Thanks for getting back to me. That sounds reasonable enough, except...
>
>I have a bit of an issue with one SDO that has a temp-table joined
>one-to-one with a live database table -- the add, change, and delete
>functionality works perfectly against the live db table, even accross
>the AppServer boundary! It sounds like going client-only will mean that
>I'll have to handle all the stuff in PLiPs, not just the population of
>the temp-table. I'm I mistaken here?
>
>I suspect in this case, there is a way to retain the full SDO functionality
>(even if it was never intended to be used this way) and still be able to
>initiate rebuilds of the temp-table from the client side... In this
>particular
>case the rowobject record only contains data from the live db table, and the
>temp-table is used as a mechanism to efficiently extract record sets from a
>table with a large number of records, in a way that would not be possible by
>manipulating the query string of the table itself. It works really well.
>
>What do you think?
>
>-Tom
>
>=========================
>
>Date: Thu, 16 Jan 2003 09:51:06 +1100
>From: Simion Legian
>Content-type: text/plain; charset=us-ascii
>Subject: RE: Populating temp table SDO's
>
>
>
>Hi Tom,
>
>
>
>Peter is right, you have to run the SDO in full client mode to get it work
>properly otherwise you risk to lose your temp-table or waste time rebuilding
>the temp-table each time a server-side call is made. The attribute you have
>to set (or should I say unset) is AppService - it should be blank, so the
>SDO will be started on the client side only. That means both the SDO and the
>LP cannot have database references; you'll get run-time errors otherwise.
>Write a separate PLIP that has all the db required code and fire it on
>request. That "buildTemp" procedure of yours should be placed in this extra
>PLIP. Make a call to the buildTemp from initializeObject (before super) if
>OpenOnInit is yes and you should be fine. Make a similar code whenever you
>need to refresh the temp-table.
>
>We have a few temp-table SDOs running fine over here, let me know if you
>need more help.
>
>SiL
>
>
>
>
>To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
>For additional commands, e-mail: dev-help@icf.possenet.org
>
>
>
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Clarification:
The inconsistent state occurs because the rowobject temp-table stores
both the rowid of the real database table and the rowid of the
temp-table in a field in the rowobject temp-table. If you refresh the
temp-table without refreshing the rowobject table the rowids don't match.
Or am I missing something?
Matt Baker wrote:
Hi Tom,
>
Once you start rebuilding the temp-table on the client side you end up
changing the rowids that are associated with them in the rowobject
table. What you'll end up with if you don't refresh the entire query
is the rowids stored in the rowobject table won't match the real
rowids of the temp-table that exists in memory after you rebuild only
the temp-table.
>
You'll end up in an inconsistent state with rowids that don't exist
because your temp-table has a completely different set of rowids.
>
Unless someone has a more creative idea, you'll have to bite the
bullet and refresh the whole query from the server.
>
I have tried doing something just like this in the past and it caused
problems with repositioning when doing batches.
>
mattB
>
Tom Greenwood wrote:
>
>> Hi Simion,
>>
>> Thanks for getting back to me. That sounds reasonable enough, except...
>>
>> I have a bit of an issue with one SDO that has a temp-table joined
>> one-to-one with a live database table -- the add, change, and delete
>> functionality works perfectly against the live db table, even accross
>> the AppServer boundary! It sounds like going client-only will mean that
>> I'll have to handle all the stuff in PLiPs, not just the population of
>> the temp-table. I'm I mistaken here?
>>
>> I suspect in this case, there is a way to retain the full SDO
>> functionality
>> (even if it was never intended to be used this way) and still be able to
>> initiate rebuilds of the temp-table from the client side... In this
>> particular
>> case the rowobject record only contains data from the live db table,
>> and the
>> temp-table is used as a mechanism to efficiently extract record sets
>> from a
>> table with a large number of records, in a way that would not be
>> possible by
>> manipulating the query string of the table itself. It works really well.
>>
>> What do you think?
>>
>> -Tom
>>
>> =========================
>>
>> Date: Thu, 16 Jan 2003 09:51:06 +1100
>> From: Simion Legian
>> Content-type: text/plain; charset=us-ascii
>> Subject: RE: Populating temp table SDO's
>>
>>
>>
>> Hi Tom,
>>
>>
>>
>> Peter is right, you have to run the SDO in full client mode to get it
>> work
>> properly otherwise you risk to lose your temp-table or waste time
>> rebuilding
>> the temp-table each time a server-side call is made. The attribute
>> you have
>> to set (or should I say unset) is AppService - it should be blank, so
>> the
>> SDO will be started on the client side only. That means both the SDO
>> and the
>> LP cannot have database references; you'll get run-time errors
>> otherwise.
>> Write a separate PLIP that has all the db required code and fire it on
>> request. That "buildTemp" procedure of yours should be placed in this
>> extra
>> PLIP. Make a call to the buildTemp from initializeObject (before
>> super) if
>> OpenOnInit is yes and you should be fine. Make a similar code
>> whenever you
>> need to refresh the temp-table.
>>
>> We have a few temp-table SDOs running fine over here, let me know if you
>> need more help.
>>
>> SiL
>>
>>
>>
>>
>> To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
>> For additional commands, e-mail: dev-help@icf.possenet.org
>>
>>
>>
>>
>
>
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
>
>
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Tom,
All I was saying is that if your SDO is built against a temp-table (meaning
the main object the SDO manipulates is that temp-table) you should run in
full client mode and use separate routines to pass it back and forth the
appserver.
The SDO you describe sounds like a different problem to me. Your SDO
maintains a database table, the temp-table is used only to optimise the
query (or make it work). So far I haven't run across such a configuration,
so I'm afraid I can't give you a clear answer/proven solution here. Can you
give more details about the thing you are trying to build, before I jump in
with "creative" ideas?
Regards,
Simi
-Original Message-
Sent: Friday, 17 January 2003 05:01
To: dev@icf.possenet.org
Subject: RE: Populating temp table SDO's
Hi Simion,
Thanks for getting back to me. That sounds reasonable enough, except...
I have a bit of an issue with one SDO that has a temp-table joined
one-to-one with a live database table -- the add, change, and delete
functionality works perfectly against the live db table, even accross
the AppServer boundary! It sounds like going client-only will mean that
I'll have to handle all the stuff in PLiPs, not just the population of
the temp-table. I'm I mistaken here?
I suspect in this case, there is a way to retain the full SDO functionality
(even if it was never intended to be used this way) and still be able to
initiate rebuilds of the temp-table from the client side... In this
particular
case the rowobject record only contains data from the live db table, and the
temp-table is used as a mechanism to efficiently extract record sets from a
table with a large number of records, in a way that would not be possible by
manipulating the query string of the table itself. It works really well.
What do you think?
-Tom
=========================
Date: Thu, 16 Jan 2003 09:51:06 +1100
From: Simion Legian Content-type: text/plain; charset=us-ascii
Subject: RE: Populating temp table SDO's
Hi Tom,
Peter is right, you have to run the SDO in full client mode to get it work
properly otherwise you risk to lose your temp-table or waste time rebuilding
the temp-table each time a server-side call is made. The attribute you have
to set (or should I say unset) is AppService - it should be blank, so the
SDO will be started on the client side only. That means both the SDO and the
LP cannot have database references; you'll get run-time errors otherwise.
Write a separate PLIP that has all the db required code and fire it on
request. That "buildTemp" procedure of yours should be placed in this extra
PLIP. Make a call to the buildTemp from initializeObject (before super) if
OpenOnInit is yes and you should be fine. Make a similar code whenever you
need to refresh the temp-table.
We have a few temp-table SDOs running fine over here, let me know if you
need more help.
SiL
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Matt, et al,
I don't mind biting the bullet, I'm just not sure how to recreate the
temp-table
on the server-side. I need to initiate the rebuild of the temptable from an
event
on the client (eg. a button being pushed). Then somehow, pass a parameter
string to
rebuild the temptable on the server-side SDO such that it re-populates the
rowobject temptable, and sends it back across...
TIA
Tom
-Original Message-
Sent: Thursday, January 16, 2003 1:11 PM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Tom,
Once you start rebuilding the temp-table on the client side you end up
changing the rowids that are associated with them in the rowobject
table. What you'll end up with if you don't refresh the entire query is
the rowids stored in the rowobject table won't match the real rowids of
the temp-table that exists in memory after you rebuild only the
temp-table.
You'll end up in an inconsistent state with rowids that don't exist
because your temp-table has a completely different set of rowids.
Unless someone has a more creative idea, you'll have to bite the bullet
and refresh the whole query from the server.
I have tried doing something just like this in the past and it caused
problems with repositioning when doing batches.
mattB
Tom Greenwood wrote:
Hi Simion,
Thanks for getting back to me. That sounds reasonable enough, except...
I have a bit of an issue with one SDO that has a temp-table joined
one-to-one with a live database table -- the add, change, and delete
functionality works perfectly against the live db table, even accross
the AppServer boundary! It sounds like going client-only will mean that
I'll have to handle all the stuff in PLiPs, not just the population of
the temp-table. I'm I mistaken here?
I suspect in this case, there is a way to retain the full SDO
functionality
(even if it was never intended to be used this way) and still be able to
initiate rebuilds of the temp-table from the client side... In this
particular
case the rowobject record only contains data from the live db
table, and the
temp-table is used as a mechanism to efficiently extract record
sets from a
table with a large number of records, in a way that would not be
possible by
manipulating the query string of the table itself. It works really well.
What do you think?
-Tom
=========================
Date: Thu, 16 Jan 2003 09:51:06 +1100
From: Simion Legian Content-type: text/plain; charset=us-ascii
Subject: RE: Populating temp table SDO's
Hi Tom,
Peter is right, you have to run the SDO in full client mode to
get it work
properly otherwise you risk to lose your temp-table or waste
time rebuilding
the temp-table each time a server-side call is made. The
attribute you have
to set (or should I say unset) is AppService - it should be blank, so the
SDO will be started on the client side only. That means both the
SDO and the
LP cannot have database references; you'll get run-time errors otherwise.
Write a separate PLIP that has all the db required code and fire it on
request. That "buildTemp" procedure of yours should be placed in
this extra
PLIP. Make a call to the buildTemp from initializeObject (before
super) if
OpenOnInit is yes and you should be fine. Make a similar code
whenever you
need to refresh the temp-table.
We have a few temp-table SDOs running fine over here, let me know if you
need more help.
SiL
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Hi Matt, et al...
Thanks for respnding earlier. I have modified this particular SDO so that
the string that was originally an input parameter to the
"buildTemp" routine is now set and retrieved via the session manager, using
the get/set propertyList functions as you suggested.
The string's value is correctly passed to the server-side SDO.
I have tried initiating the rebuild of the SDO temp-table just prior to the
RETURN SUPER() of an openQuery override on the server --
I imagined that the SUPER of openQuery server-side would create the
rowobject temptable, whose data is sourced by the temp-
table. However, what I get returned to the client is (*!) every record of an
actual database table on which the temptable was based
during the creation of the SDO.
Is there any known problem with using a live db table as a model for a
temptable for a split SDO? Because it looks like either:
a) I have not put the temp-table build in the right place (-- but even
then, I have no idea how it gets populated with ALL the data in
the live table) ... or
b) I have come across a bug where the split SDO confuses the live db table
with the temp-table when transferring data to the
rowobject table.
I have tried overriding a few other super procedures and functions in the
SDO, but get the same incorrect result.
Before I go and create a new version of this thing with a temp-db temp-table
I was hoping someone could shed some light on whether
my problem is a) or b) above...
Thanks again,
Tom
-Original Message-
Sent: Friday, January 17, 2003 12:05 PM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Tom,
At its simplest form you simply need to call closeQuery followed by an
openQuery in the SDO. This will discard your entire result set on the
client and refresh from the server. I'll assume for a moment that you are
using dynamics. If you need a certain set of parameters passed to the
server from the client in order to filter the results in the temp-table
correctly, then you can set a property suing "setpropertylist" in the
session manager and retrieve it on the server side with getPropertyList..
If your not using dynamics, then you'll have to get a bit more creative.
There are ways to do it fairly transparently, but they're beyond the scope
of what I'm prepared to suggest. Someone else might have more experience in
passing non-query related data across an appserver boundary to an sdo in
order for it to filter its query properly.
mattB
Tom Greenwood wrote:
Hi Matt, et al,
I don't mind biting the bullet, I'm just not sure how to recreate the
temp-table
on the server-side. I need to initiate the rebuild of the temptable from an
event
on the client (eg. a button being pushed). Then somehow, pass a parameter
string to
rebuild the temptable on the server-side SDO such that it re-populates the
rowobject temptable, and sends it back across...
TIA
Tom
-Original Message-
Sent: Thursday, January 16, 2003 1:11 PM
To: dev@icf.possenet.org
Subject: Re: Populating temp table SDO's
Hi Tom,
Once you start rebuilding the temp-table on the client side you end up
changing the rowids that are associated with them in the rowobject
table. What you'll end up with if you don't refresh the entire query is
the rowids stored in the rowobject table won't match the real rowids of
the temp-table that exists in memory after you rebuild only the
temp-table.
You'll end up in an inconsistent state with rowids that don't exist
because your temp-table has a completely different set of rowids.
Unless someone has a more creative idea, you'll have to bite the bullet
and refresh the whole query from the server.
I have tried doing something just like this in the past and it caused
problems with repositioning when doing batches.
mattB
Tom Greenwood wrote:
Hi Simion,
Thanks for getting back to me. That sounds reasonable enough, except...
I have a bit of an issue with one SDO that has a temp-table joined
one-to-one with a live database table -- the add, change, and delete
functionality works perfectly against the live db table, even accross
the AppServer boundary! It sounds like going client-only will mean that
I'll have to handle all the stuff in PLiPs, not just the population of
the temp-table. I'm I mistaken here?
I suspect in this case, there is a way to retain the full SDO
functionality
(even if it was never intended to be used this way) and still be able to
initiate rebuilds of the temp-table from the client side... In this
particular
case the rowobject record only contains data from the live db
table, and the
temp-table is used as a mechanism to efficiently extract record
sets from a
table with a large number of records, in a way that would not be
possible by
manipulating the query string of the table itself. It works really well.
What do you think?
-Tom
=========================
Date: Thu, 16 Jan 2003 09:51:06 +1100
From: Simion Legian Content-type: text/plain; charset=us-ascii
Subject: RE: Populating temp table SDO's
Hi Tom,
Peter is right, you have to run the SDO in full client mode to
get it work
properly otherwise you risk to lose your temp-table or waste
time rebuilding
the temp-table each time a server-side call is made. The
attribute you have
to set (or should I say unset) is AppService - it should be blank, so the
SDO will be started on the client side only. That means both the
SDO and the
LP cannot have database references; you'll get run-time errors otherwise.
Write a separate PLIP that has all the db required code and fire it on
request. That "buildTemp" procedure of yours should be placed in
this extra
PLIP. Make a call to the buildTemp from initializeObject (before
super) if
OpenOnInit is yes and you should be fine. Make a similar code
whenever you
need to refresh the temp-table.
We have a few temp-table SDOs running fine over here, let me know if you
need more help.
SiL
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To
unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org For additional
commands, e-mail: dev-help@icf.possenet.org