We're in the process of centralizing all our print queues. The process to migrate user settings is time consuming and we have decided to automate some elements based on our need to replicate this effort on other Baan instances.

Here's what I need to do:

Look for a record in ttaad300 (Devices) if it exists then use all values to create a new record (only the device name and queue will change).

I could use holding variables to store all values prior to reselecting the ttaad300 for update (insert), but I would prefer to save the record into the buffer and retrieve as needed. The only problem is I can't recall how.

Could anyone send me an example of the logic or else direct me to a standard session that does this ?

I've done this in the past, but it's been a while.

Thanks in advance.

BaanTech

Yes, you can do multiple selects on the same table.

an example -

http://www.baanboard.com/baanboard/showthread.php?s=&threadid=5885&highlight=distinct

you can also use functions like -

http://www.baanboard.com/programmers_manual_baanerp_help_functions_db_operations_on_main_table

and

http://www.baanboard.com/programmers_manual_baanerp_help_functions_db_operations_with_object_set_do


Table names and declarations
The naming syntax for tables, record buffers, and fields is:

table tppmmmxxx | table declaration
rcd.tppmmmxxx | record buffer of table
ppmmmxxx.ffffffff | logical field of table
where t stands for table, pp is the package code, mmm is the module code, xxx is the table number, and ffffffff is a field name.

If a table is used in a script, it must be declared with the statement: table tppmmmxxx

Declaration of a table implies declaration of all its fields and its record buffer. These do not need to be declared separately.

There are no functions for opening or closing a table. A table is automatically opened the first time it is accessed. It is automatically closed when the program ends.


http://www.baanboard.com/programmers_manual_baanerp_help_functions_db_operations_overview

Looks familar, but what I need to do is basically have the system take all values

I can do this myself by basically storing all the field values before selecting the table again for update. In my case I really don't care what happens to the original record as long as I can copy it to create the new record. Can we somehow emulate the logic used in sessions when the copy option is selected via the form - in this case the copy would be within single-occurence. Table ttaad300 is not the main table for this session. Can I apply the stored values to a new record and have control of changing specific fields before updating ?

Here is the code where tuxch950.odvn is the source device and tuxch950.ndvn is the target device.


select ttaad300.*
from ttaad300
where ttaad300._index1 = {:tuxch950.odvn}
and ttaad300._compr = 000
order by ttaad300._index1
as set with 1 rows
selectdo
|*** Store old values
select ttaad300.*
from ttaad300 for update
where ttaad300._index1 = {:tuxch950.ndvn}
and ttaad300._compr = 000
order by ttaad300._index1
as set with 1 rows
selectdo
selectempty
|*** Use old values for new values
db.insert(tttaad306, db.retry)
commit.transaction()
endselect
endselect

Thanks.

BaanTech

The table buffers are always available for every table opened.


Can we somehow emulate the logic used in sessions when the copy option is selected via the form - in this case the copy would be within single-occurence.


--> use AFS/API calls.

By reselecting the table for update I've lost my pointer to the original record selected. Unless I save all values before the select I won't be able to use them for assigning values to the
new key. This is unless of course they are still available for me
somewhere for retrieval.

AFS/APIs sounds like another viable approach, but what functions are available for this specific issue?

Surely someone out there has had a request to automate a mass copy.

In my case I'm doing devices and the number of fields involved is not much, but hasn't anyone tried to do something like emulate a copy of the item master from a defined list.

I'm creating this logic from scratch as we need to add additional
logic to also convert some default devices applicable to some of our customized processes. The overhead needs to be one source file, minimal setup. I'm not looking to have to create/setup AFS/APIS/DDCs etc.

Thanks.

BaanTech

Yes you might loose the record pointers or values.

as an example, so you have to use -

db.row.length(ttccom130,l.rcd.tccom130.length)
alloc.mem(l.save.rcd.tccom130, l.rcd.tccom130.length)
l.save.rcd.tccom130 = rcd.ttccom130


For the other info, you can search for the postings on the board.

AFS/DDC/OLE: Function servers (http://www.baanboard.com/baanboard/forumdisplay.php?s=&forumid=59)

How about...


db.retry.point()
select ttaad300.*
from ttaad300
where ttaad300._index1 = {:tuxch950.odvn}
and ttaad300._compr = 000
order by ttaad300._index1
as set with 1 rows
selectdo
ttaad300.???? = tuxch950.ndvn |* key field?
db.insert(tttaad300, db.retry) |* you referenced ttaad306 before
commit.transaction()
endselect

Sorry all the code should have been for ttaad300, and ttaad306 was incorrect. Don't I need to select the table for update at some point (not the main table) ? Or can I do a db.insert to a
table by simply changing the key ?

PS. Other elements of my script are keeping my from compiling
at this point, plus because of meetings I'm basically checking
the forum for updates when I can.

I'll have to try testing out if I can db.insert without update as
soon as I can.

Regards,

BaanTech

No need to use rdi.column, or select for update etc.

This works ...

function update.device.data()
{
switch.to.company(000)

db.retry.point()
select ttaad300.*
from ttaad300
where ttaad300._index1 = {:tuxch950.odvn}
order by ttaad300._index1
as set with 1 rows
selectdo
ttaad300.devc = tuxch950.ndvn
ttaad300.pcom = tuxch950.ndvq
db.insert(tttaad300, db.retry)
commit.transaction()
endselect
switch.to.company(company.number)
}

Thanks.

BaanTech

Good that you could fix it.

Be aware of -


compnr.check() and switch.to.company() perform similar functions, but switch.to.company() performs additional checks. So switch.to.company() makes heavier demands on system resources.


You can improvize using -


where ttaad300._index1 = {:tuxch950.odvn}
and ttaad200._compnr = 000
....
db.insert(tttaad300, db.retry, db.skip.dupl)

Doesn't the switch to company go further and check that the login is authorized for the company (or something like that). You're right, I guess in my case I could use *._compnr = 000
instead, but the majority of my selects & updates will be in 000
so I figured two switch.tos shouldn't be too bad ... I am however
doing this for every record in tuxch950 ... you recommend to
try to avoid switch.to if possible ... when would this not be
an option ?

I would recommend switch.to.company() if only I need to totally switch into the tools company to do more processing, updating on tools tables etc.

For light weight processing I prefer to use the compnr.check().

for spot checks/values I use _compnr = 000. This is more preferred in my case as most of my own add-on code is located in my DLLs, and our sessions/utlities call them. who knows our developers might use my code too ;-) like my email/excel interfaces. My assumption this always works, because to work in BaaN even if you are super or normal user, you need to have atleast read access to the tools tables.

yes the switch.to.company() is more secure but most of the time I use those sessions and not the common people/developers so I am a superuser and I have the full authority. So that makes my utilities performance.

Ofcourse thats my own methodology of doing things, I believe everyone has one.

Just wanted to share thoughts :p