Powerbuilder - Retain previously retrieved data - powerbuilder

I am doing multiple retrievals of a composite datawindow and the request was to have them all in one printout.
I vaguely remember that in the past I was putting something in the RetrieveEne event that retained the data but I cannot recall or locate it in my previous code listings.
Could you help me on this?

I found it here
Return 2 in RetrieveStart Event


Subclass a table and a big trouble in Delphi

alt text http://img29.imageshack.us/img29/825/simplemodel.jpg
How you can see above, it's a kind of subclass a table in a RDBMS (in this case, my favorite: MySQL) so I handle it with Visual Subclassing a base form for tb_order_base with validating field data, etc.
This way, I'm free of repeating code and some other bothering problems, well, it seems a true OO aproach. But ...
Now I got a Big problem with subclassed form i.e. tb_order_service with a master/detail approach, when I post the tb_order_base dataset, instead of Delphi first post it and get the PK ID from RDBMS and then post the TB_ORDER_PRODUCT with id filled, it does the opposed, posting the detail tb_order_product dataset first then master tb_order_base, so I get a big foreing key constraint error.
Does anyone has any idea to how to by-pass this amazing problem?
I have asked it before, but with few details in The Master/Detail Behavior
One thing I have done in such a condition was to break away from doing DBMS direct calls, and to instead use a memory dataset (or client dataset) for the form. When the user presses the save button, I would validate my edits and return any errors. If no errors then I would begin a database transaction, commit the master record (and then read the master record key back if its an insert), then run thru each table commiting the child records, followed by a commit of the transaction (or rollback if there were any problems saving child data).
I also stay away from using data-aware components. They work great for simple utility type programs, but when you start creating a complex system using them you will find little gotchas along the way that are easily solved by using a standard edit and a function to push/pull data to/from the database. The only exception I generally make would be for grids, but I only use the grid for selection...the actual editing is done using non data-aware components.

The 'invalid field type' error with TClientDataSets I don't understand

I use nested database stuctures with TClientDataSets. I'm new to programming so my lingo is ten-to-one wrong.
My problem is as follows: I defined my database stucture and all the fields of the nested stuctures and then I called the CreatDataSet method of the master clientDataSet and it worked. I then wanted to add another data field to the master ClientDataSet. I then called the ClearData method of the Master ClientDataSet and then tried to create the new stucture by calling CreateDataSet again. It is here where I encounter my problem. I get the 'Invalid field type error' and I don't really know or understand what what the problem is.
So how do I create an exsta field after I called the createdata set method, then called the cleardata method, then added a field and then calling the createdataset method again without getting the 'invalid field type error?
Does anybody have any information about this problem. I use Delphi 2007
Kind Rgards
Riaan de Villiers
It is a Delphi bug.
Call YourDataset.FieldDefs.Clear before calling CreateDataSet and it should work.
For more infomation please look at this QC Report:
After reading your problem more carefully, the problem might be something else, but please try the FieldDefs.Clear and let me know the results.
It has been a long time since you asked this question, but I believe the problem has specifically to do with the nested dataset fields. I've seen this error before, and I believe that it has to do with the order in which the particular fields are created. If I remember correctly, if you try to create the master dataset before the nested dataset fields are defined or created, you get this invalid field type error.
Begin by removing your nested dataset fields from the equation and see if you still get the problem. If not, then add them back. Try creating the master dataset and its nested datasets in different orders.
I know this is late, but I hope it helps.

DataSnap using AutoInc key and refresh current record only after insert

I've not been able to find an answer on this anywhere. Using Delphi XE7 with TClientDataSet, DataSnap & SQL Server. I need to insert a record, apply updates and then refresh that record so I can get the Id and assign it to my object. Seems pretty basic requirement, but on the contrary it is proving to be a royal pain.
I've found the obvious stuff on EDN, SO and Dr Bob:
DataSnap and the autoinc field
However these seem to focus on a "Refresh" of the TClientDataSet to re-fetches the entire table/query. Whilst this does actually resolve the Id field itself (good!), it also moves the cursor off the current record which was just inserted and so I'm not able to get the Id and assign it to my object. Also, for performance over HTTP I don't really want to refetch the entire table every time a record is inserted, if there's 10,000 records this will consume too much bandwidth and be ridiculously slow!
Consider the following code:
function TRepository<I>.Insert(const AEntity: I): I;
AssignEntityToDataSet(AEntity); // SET'S ALL THE RELEVANT FIELDS
FDataSet.Refresh; // <--- I tried RefreshRecord here but it cannot resolve the record
AEntity.Id := FDataSet.FieldByName('Id').AsInteger; // <----- THIS NOW POINTS TO WRONG ROW
Does anyone know how to achieve this? I need to be able to refresh and stay on the current record otherwise I do not know the Id of the record just created and the GUI cannot stay focused on the current record.
Hopefully something obvious I'm missing.
Assuming you can get hands on the new ID inside the AfterUpdateRecord event of your DataProvider, your event handler then may look like this (the current record of DeltaDS is the one just inserted into SourceDS):
if (UpdateKind = ukInsert) then begin
DeltaDS.FindField('Id').NewValue := <TheNewID>;
Make sure to have the poPropogateChanges option set in the provider. This will transfer the changed Id field back to the ClientDataSet.
Now you can get rid of the FDataSet.Refresh call.
SQL Server does allow you to get the last identity it generated in several ways - there's no need to "refresh" the record/query which means re-issuing a SELECT and can generate undesiderable side-effects. You can use SELECT SCOPE_IDENTITY() or use an OUTPUT clause. If the Delphi database driver supports it, TField.AutogenerateValue should accomplish that task automatically (see http://docwiki.embarcadero.com/Libraries/XE7/en/Data.DB.TField.AutoGenerateValue)
Otherwise you have to put that new data into your delta (see Raabe answer - this has to be done on the datasnap server which actually talks to the database) after reading it, so it's sent back to the client. You also need to set properly and TField.ProviderFlags to ensure data are applied correctly (see http://docwiki.embarcadero.com/RADStudio/XE7/en/Influencing_How_Updates_Are_Applied), usually you don't want those field appear in an UPDATE.

Change record position internally

I use disablecontrols method for master/detail tables and I am looking for a way to change the record position internally (while within disable controls) in the component level (IBDAC) without using bookmarks or locate
Try RecNo and check out Navigating Data in Client Datasets
Apart from that, I think this is probably a design issue you need to address, but I'm not sure. I normally fetch all the data I need, then a single unidirectional pass through the dataset is usually enough. If necessary, make a second pass (rarely), but I've never had to move back and forth several times within a dataset. There is probably a better way. Hope that helps.

MVC2 Poco Update when properties are not mapped to View Model

I'm after some opinions \ best practice for handling updates to my repository in the following scenario:
I am using EF 4 with the POCO tt templates which creates nice clean clr objects.
For example's sake lets say I have a POCO object name Customer and a ViewModel called CustomerViewModel. CustomerViewModel has a public property for the Customer object which is populated with the POCO Customer object.The view references the Customer object on the CustomerViewModel. So far so good. Everything is displayed as expected.
When it comes time to update the CustomerViewModel is passed back and only the properties that were bound to the view are populated, fair enough.
What I have now is a POCO object that is missing some of the property values which are needed to update via the EF data context. For example, since I did not display the ID in the view, it was not hydrated back into the view model's Customer property. Not really surprising behaviour but I am wondering what the best way to handle this scenario is.
So here is the question:
Would it be better to map the properties that i don't display into hidden fields so that I have the complete POCO object on postback which is ready for updating to the Repository? (I'm thinking there is needles sending of data to and from the client here)
OR should I do a read of Customer before my update(assuming I have the ID) and then update the properties from my view model object. ( is this a needles read on the database ?).
OR is there another may altogether that I am missing.
I realise that maybe there is no one correct answer for this but I'd be interested to hear how others are handling this scenario.
I'm going to answer my own question here... maybe it was a silly question but the act of writing it out has made the answer more obvious..
The first option of populating hidden fields is a bad idea for too many reasons!! So I think I'll have to go with doing a read of the customer object on the post back and calling.
TryUpdateModel(customer, "Customer");
Where customer is the freshly read Customer and "Customer" is the property name on the view model.
It seems that this results in more data access than in a classic ASP where the object could have been shoved (rightly or wrongly) into Session !
Anyone care to add their 2c ?