Baanboard.com

Go Back   Baanboard.com > Forum > Baan Quick Support: Functional & Technical > Tools Development

User login

Frontpage Sponsor

Main

Poll
For ERP LN feature pack upgrade, what method of install are you using?
Installation Wizard into existing VRC
37%
Installation Wizard into new VRC
39%
Manual into existing VRC
3%
Manual into new VRC
21%
Total votes: 38

Baanboard at LinkedIn


Reference Content

Reply
 
Thread Tools Display Modes
  #1  
Old 22nd February 2017, 14:17
VishalMistry's Avatar
VishalMistry VishalMistry is offline
Guru
 
Join Date: Dec 2004
Location: India, Gujarat
Posts: 573
VishalMistry has a little shameless behaviour in the past
Baan: Baan IV, ERPLn - DB: SQL Server 2000 / 2008 - OS: Windows Server 2003 / 2008
Red face store.* and load.*
Baan: Baan IVc4
C/S: Server

Hello Everyone,

I just came to know about store.* (store.long / store.byte / store.store) and load.* functions.

From the Baan manual, it indicates that it stores particular numeric value in its real machine dependent binary form in string variable.

It sparked off some questions in my mind:

1.Why use store.long and load.long when we can store numeric values in numeric variable straight forward way.
2.Are these functions efficient in any way ? if yes then how they differ or how they are efficient technically then usual way to store and retrieve numeric values in numeric variable.


Shall be grateful if somebody can explain.
Any additional information will be highly appreciated.

Vishal
Reply With Quote
  #2  
Old 22nd February 2017, 16:54
vahdani's Avatar
vahdani vahdani is offline
Guru
 
Join Date: Aug 2002
Location: Cologne, Germany
Posts: 418
vahdani is on a distinguished road
Baan: all - DB: all - OS: Unix / Win2K
Hello Vishal,

as stated in help
Quote:
function is machine independent and can be used (for example) in network communications
I think These functions are there if you want to communicate with an external system which uses binary data and not the usual ASCII-files.
__________________
May the force be with you!
Reply With Quote
  #3  
Old 23rd February 2017, 06:13
oirfeodent's Avatar
oirfeodent oirfeodent is offline
Member
 
Join Date: Jun 2016
Posts: 51
oirfeodent is on a distinguished road
Baan: Baan - DB: DB - OS: OS
Quote:
Originally Posted by VishalMistry View Post
Hello Everyone,

I just came to know about store.* (store.long / store.byte / store.store) and load.* functions.

From the Baan manual, it indicates that it stores particular numeric value in its real machine dependent binary form in string variable.

It sparked off some questions in my mind:

1.Why use store.long and load.long when we can store numeric values in numeric variable straight forward way.
2.Are these functions efficient in any way ? if yes then how they differ or how they are efficient technically then usual way to store and retrieve numeric values in numeric variable.


Shall be grateful if somebody can explain.
Any additional information will be highly appreciated.

Vishal
One use in practical application.
1) store an integer as it is in a string array and sort that value. You will notice, " 100ABC" and " 10ABC" will give you misleading values at run time.
But, if load.integer() is used to load it to the four bytes and suffixed with ABC the sorting will be consistent.

Regards,
Reply With Quote
  #4  
Old 23rd February 2017, 09:37
vahdani's Avatar
vahdani vahdani is offline
Guru
 
Join Date: Aug 2002
Location: Cologne, Germany
Posts: 418
vahdani is on a distinguished road
Baan: all - DB: all - OS: Unix / Win2K
Hi oirfeodent,

in your case I would have used the edit$() function to generate string representations of the same lenght: 00010ABC, 00100ABC, etc.

This would be definitly easier to read and understand later on.
__________________
May the force be with you!
Reply With Quote
  #5  
Old 24th February 2017, 08:13
oirfeodent's Avatar
oirfeodent oirfeodent is offline
Member
 
Join Date: Jun 2016
Posts: 51
oirfeodent is on a distinguished road
Baan: Baan - DB: DB - OS: OS
Quote:
Originally Posted by vahdani View Post
Hi oirfeodent,

in your case I would have used the edit$() function to generate string representations of the same lenght: 00010ABC, 00100ABC, etc.

This would be definitly easier to read and understand later on.
True, edit$() looks easier if you know how your run-time data looks all the time.
I've seen few times, were code is written with edit$() and at run-time... negative integer comes and the representation looks odd "000-10ABC"....
Off course, this can also be rectified with a properly thought off code.

But, I started using store.* & load.* as I dont have to write a code to pad 16 Zeros... when dealing with double.

Regards,
Reply With Quote
Sponsored Links
  #6  
Old 27th February 2017, 03:53
BaanInOhio BaanInOhio is offline
Senior Member
 
Join Date: Oct 2005
Location: Northeast Ohio
Posts: 180
BaanInOhio is on a distinguished road
Baan: Baan 4c4, 5C, LN - DB: Informix, Oracle, SQL - OS: HP UX, Win2K
I have used these to read and update individual fields in the internal record buffer filled by a select statement. You can use the db.store.record and db.restore.records to save the full buffer (rcd.tdsls400, for sales orders) that includes the extended fields for locks and reference counts. Since these records will include embedded nulls, you can't manipulate them using normal string functions since they truncate the record. The load.* call in combination with rdi.table.column's "offset" field will allow pulling of variables from the buffer. The store.* calls do the opposite, where values in the record buffer can be changed from local variables.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +2. The time now is 09:35.


©2001-2017 - Baanboard.com - Baanforums.com