Hi!

Tableupdate() has nothing to data integrity. If you're making changes in few tables simultaneously, it is required to use transaction for better reliability. Do all tableupdate(), then END TRANSACTION if all ok.



>Thanks. I was hoped for something better and simpler.
>
>Now I have to:
>
>1) Redesign DE to put in form's Load
>2) Change all code and controls (probably, by hacking SCX) to use proper aliases.
>
>Once again, it's a confirmation of bad original design, when I can not easily change "data layer".
>
>Oh, well, have today few other projects to work on, so probably will start this route on Monday...
>
>One more quick question:
>
>I'm planning to use code like:
>

>select * from dbf('JobsFrom') into cursor JobsMove nofilter where lSelected
>
>select * from dbf('JobStepsFrom') into cursor JobStepsMove nofilter where JobID in (select JobID from JobsMove)
>....
>
>select JobsTo
>append from dbf('JobsMove')
>select JobStepsTo
>append from ...
>
>delete from JobsFrom where JobID in (select JobID from JobsMove)...

>
>Should I wrap the whole process in BEGIN TRANSACTION/END TRANSACTION or only tableupdate part of it (our BaseForm code has TableUpdate wrapped into transactions already)?
>
>Do you see problems in the above code prototype?
>
>Thanks in advance.
>
>
>
>>Hi!
>>
>>No other suggestions...
>>
>>As Alejandro demonstrated, it is not that confusing - just looks what set of tables is "From" (that you display on form) and "To" (into which records will be moved).
>>
>>>That's a little bit confusing, but may work... Do you see other possibilities here?
>>>
>>>>Hi!
>>>>
>>>>Well, what is wrong with
>>>>
>>>>USE Jobs alias Jobs in 0
>>>>
>>>>AND
>>>>
>>>>USE JobsArch alias JobsArchs in 0
>>>>
>>>>in one mode, and
>>>>
>>>>
>>>>USE JobsArch alias Jobs in 0
>>>>
>>>>AND
>>>>
>>>>USE Jobs alias JobsArchs in 0
>>>>
>>>>in second mode???
>>>>
>>>>In the Load event of the form you open a set of tables. Depenent on some public variable or setting, you open usual or "Arch" set of tables with corresponding aliases as a main tables ("Jobs" alias), and additinal tables into which you will copy records is opened as "Arch" set. You just switch between them. :-)
>>>>
>>>>When you switching to another set of tables from the form, just re-load the form...
>>>>
>>>>HTH.
>>>>
>>>>>>Move tables from DE into Load method code?
>>>>>>
>>>>>
>>>>>Well, it would not solve the problem. All controls reference tables without "Arch". Since I will have to open another set anyway to perfrom my operation, I can not alias "Arch" tables without "Arch"
>>>>>
>>>>>See my problem? If we would use n-tier design, where data layer is separated from presentation layer, I would not have this problem...
>>>>>
>>>>>>>Hi everybody,
>>>>>>>
>>>>>>>I have Jobs, JobSteps, JobsHist, Delivery tables in JobControl database. I have JobsArch, JobStepsArch, JobsHistArch, DeliveryArch in the same database. I also have a form which uses first set of tables in its DE and all controls (grid, textboxes, etc.) are bound to these tables directly.
>>>>>>>
>>>>>>>I have to invoke this form in two modes - Archive (user selects jobs from jobs table and these jobs and related info are put into corresponding "arch" tables). I also need to perform the opposite operation - UnArchive - e.g. put "archived" jobs back into production (assign a new ID to avoid conflicts, though).
>>>>>>>
>>>>>>>So, my question is: how should I approach the second mode? The form I took from my colleague and just modified to fit my needs. How should I make this form to operate on the "arch" tables?
>>>>>>>
>>>>>>>Another idea would be to create a clone of the form and hack (or somehow) change all controlsources and DE. However, two forms are harder to maintain.
>>>>>>>
>>>>>>>I understand, that this is against n-tier design, but the form was designed using tables directly and bound controls...
>>>>>>>
>>>>>>>Would appreciate your ideas.
>>>>>>>
>>>>>>>Thanks in advance,