|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| [WD] Question about HRecNum |
| Débuté par Markus K., 29 mar. 2015 13:35 - 10 réponses |
| |
| | | |
|
| |
Posté le 29 mars 2015 - 13:35 |
Hi,
i am not sure if i use HRecNum correctly:
A table shows all contacts or can seek for specific contacts. To view and edit a contact the user has to doubleclick a contact in the table and then a separate windows opens. In the end of initialization code i use hreadseekfirst(contact, ...) and store the recnum in a variable nRecNum = hRecNum(contact).
If the user changes something and wants to store the changes i use hModify(contact, nRecNum).
I am not sure if it is ensured that always the correct contact is modified and not another contact.
Is this correct or can this cause some trouble?
If the window is non modal and the user changes the content of the table with the customers by searching for a name or customer number, will the recnum of the opened contact windows stay the same or can it change?
Thanks and greetings,
Markus |
| |
| |
| | | |
|
| | |
| |
Posté le 29 mars 2015 - 14:08 |
Hi Markus,
The end of initialization code of the table will give you the record number of the last record in the table and this does not change until you run the initialization of the table again and then it still points to the last record.
So obviously this is a recipe for trouble.
In most cases you don't need to supply a record number to edit a record.
Just make sure that the record is loaded as the current record in memory.
All hRead functions do that.
To modify a record in a table you need to use the row selection code of the table.
Then you have several ways to do get the corresponding record, a unique identifier or a record number.
In some cases (browsing tables) the table will select the proper record automatically.
Regards,
Piet |
| |
| |
| | | |
|
| | |
| |
Posté le 29 mars 2015 - 16:43 |
Hi Piet,
i don't use it in the end of initialization code of the table, i use it in the end of init-code of the separate contact details windows. |
| |
| |
| | | |
|
| | |
| |
Posté le 30 mars 2015 - 11:45 |
Hi,
I very rarely use HRecNum.
Piet is correct... the way I do it:
I have a Table control on the window bound to a DB file (e.g. Customers), and set to no edit/selection only. I also have corresponding Edit controls on the same window that are bound to the same DB file. When a user selects a row from the Table control, I issue a HRead... in the Row Selected event followed by a Filetoscreen. The user can then amend the data to their hearts content. When they've finished they press a Save button which issues a Screentofile and a HModify. If they select another row without saving, the code simply replaces the currently selected record with the newly selected one - no problem.
HTH... |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 11:02 |
Hi,
thanks for your answers but my question is about another combination.
At program start i fill an array with all contacts. If an user searches for contacts i search the array and fill the table with matching contacts. At this time i dont know the recnum of the contacts.
The table shows only a few information about the contact, if the user wants to see all details and/or wants to edit the contact he has to doubleclick a contact and a separate window opens in which he can see and edit all contact information. In the end of initialization code of the window i use hreadseekfirst(contact...) and then i save the recnum of the contact in a variable nrecnum.
If the user changes something i use hmodify(contact, nrecnum).
The user can open more than one contact detail windows and can change the search parameters for contacts and the table's content changes then too.
Does this affect the hrecnum of the contacts which are opened in the detail windows? Or wont they change? |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 11:15 |
Hi,
Still the same - I never use the record number for a DB record. In the Analysis, I always define an auto incrment (unique) ID to every reocrd written to the DB. This ID is also what I use in foreign key relationships; never recnum.
If you use recnum, there's always the possibility that if you re-org your DB, recnum's will be re-claimed by the DB and especially problematic is that using recnum could mess up your foreign keys also. With unique IDs they always remain the same as they exist independently of recnum's. |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 12:00 |
Hi,
in an earlier version the user could open only one detail window as modal window. So the ID of the contact didnt changed and i just used hmodify(contact).
Now the user can open more than one window and so it is not sure anymore that the ID of the current viewed contact is still the same as it was while opening the detail window because the pointer in the database points to another contact. hmodify(contact) can modify the wrong contact.
I could use a check (if contact.id <> nIDWhileOpeningWindow then hreadseekfirst(contact, id, nIDWhileOpeningWindow)) before each hmodify(contact) but i thought hmodify(contact, nrecnum) would be much easier. |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 12:50 |
Markus,
That changes things a bit. This isn't a question about using ID or recnum, it's a question of design, process flow and what you allow your users to do after they have selected a Contact. This is something that's difficult to help with because I don't know why you would allow a user to open more than one window allowing them to change their view of the data but then allow them to do an modification "along the way"? |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 13:26 |
Hi Darren,
an example: a user is working on a contact (adds some activities or contact persons, changes address etc) and then a customer calls. The user can now open the contact view of the caller without closing the contact view he is working on. Maybe the caller moved and his address changed. The user can update the contact and save the changes and can go on working on the other contact which is still opened.
Same with offers or invoices. |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 15:02 |
Hi Markus,
Simply set the window with independent HFSQL context and you will have no issues at all.
<a class="ExternalLink" rel="nofollow" target="_blank" href="http://doc.windev.com/en-US/?1010029">http://doc.windev.com/en-US/…</a>
Then implement the other suggestions. When the window opens, read the record, push data to screen, on user validation push back the data to the record and save.
Using HRecNum should almost never happen usually, unless you make a search with no read (like HSeek, HSeekFirst, HSeekLast) and you want to make an action, like deleting, etc.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
Posté le 31 mars 2015 - 15:14 |
Hi Markus,
In addition to what Alexandre states, you might also consider reading records in the state you need them; i.e. reading in read-only (hLockNo), on viewing windows and reading (without hLockNo - default), for records you intend to modify or delete?
WD help states hLockNo; No lock (even if HStartLock was called): the record can be read or modified by another application during the read operation. |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|