James Bott wrote:Hmm, well I didn't know because in the reservation database you sent me that field is named NUMPRE, and it is 18 digits long. The fieldname didn't sound like RESNO, RESID or similar, and I don't even know how big of a number is 18 digits long (1,000 trillion). Wow, that is a lot of reservations for only a 3 month period. Why such a huge field, maybe a government requirement? Also, it is traditional to have the ID field as the first field--and this also allows you to always use setOrder(1), to search the primary-key field in any database.
My ID fields are usually 6 digits, as that handles one less than a million numbers.
I honestly don't understand what your common thread is and what the reservation number has to do with it.No government requirements.
Do I have to explain on the public forum how I created the NUMPRE field or the INVOICE field?
Exactly, the field is 18 characters and is a string formed by an internal code RR (reservation "or SS" single receipt "or by another code that I would like not to explain in the public forum
and is formed by
Year
the current month
the current time including seconds
are you happy that I explained on public forum how that unique code was created?I thought of this code when
* someone * insisted telling me that
with tdatabase (or tdata) I couldn't know the record number and adding +1 to the value because in ancient times the reservation number was made up of the record number - strzero (recno, 4) + 1 -
I would have liked not to publicly explain how the code is made, I don't see why this could affect the search I asked for, the order or reservation number must not be changed, it remains the same even when the record is in modification
>I'm still not sure why you would need that. Aren't you looking for available records only? Since the one you are editing is not available for it's own date range it will not show as available anyway. If you are looking to shorten the >length of stay, then you don't need to search at all.
>You can immediately just change the checkout date without any searching at all. Since you are going to free up a week (29/07/2021 is going to be changed to 21/07/2021). So you just change the 29 to 21 and save. No search >needed.
>Of course, if the customer wants to extend their stay, then you will have to search.
James,
Are you sure you have seen the archive correctly?this is the sample test I sent you I 'm edting the record number 6 where you found the NUMPRE or INVOICE NUMBER as
"RR20062313371" ( RRAAMMHHMMSS)
ROOMS_ID 0006
TYPE 01
CHECK_IN 08/07/2021
CHECK_OUT 28/07/2021
the customer want another day
until 29/07/2021I cannot automatically add a day I have to have the program search for it if it is free or busyin fact if you see well there is a record number 12 which is the same element (0006/01) and is occupied on the day 29/07/2021so I didn't understand your unhealthy idea of adding a day without doing the proper research
>This could be automated. Just build a routine that looks for all free rooms for the customer's desired date range.
> Collect them all and present in a browse of available reservations for the user to select from. They could also be >sorted by room and/or type.
yes of course, I must publish also this ?
good Naturally, the screen searches based on the search date and draws the beach section where the customer's (orange) umbrella is located
when the customer comes because he wants to be close to his friend or to change the umbrella I show him and choose with this screen
the OMB 11 on the picture is the record I 'am editing, the green boxes are free
but I had requested something elsein the simulation I sent you there were specific searchesand my question was anotherthat is, calling the Isfree () function this does not work, or rather it works the first time and then flickers
that is, it does not always perform all searches correctly, returning an incorrect value
Since from 1991/1992 ( fw for clipper Rel. 14.4 - Momos)
I use : FiveWin for Harbour November 2023 - January 2024 - Harbour 3.2.0dev (harbour_bcc770_32_20240309) - Bcc7.70 - xMate ver. 1.15.3 - PellesC - mail: silvio[dot]falconi[at]gmail[dot]com