Recent Posts
21
Language / Re: 'DROP' mnemonic with ERR= clause
« Last post by PxPlus on September 05, 2023, 02:32:56 PM »The ERR= should be on the print, not on the mnemonic.
e.g. PRINT (0,ERR-*next) 'DROP'(Win_num),
e.g. PRINT (0,ERR-*next) 'DROP'(Win_num),
22
Language / 'DROP' mnemonic with ERR= clause
« Last post by James Zukowski on September 05, 2023, 12:04:38 PM »Is including an ERR= clause in the 'DROP' mnemonic a valid construct? e.g.:
print 'drop'(Win_Num,err=*next),
It doesn't generate an error, but it also doesn't seem to trap error #57 if the specified (non-zero) window# doesn't exist.
Any insights?
print 'drop'(Win_Num,err=*next),
It doesn't generate an error, but it also doesn't seem to trap error #57 if the specified (non-zero) window# doesn't exist.
Any insights?
23
Programming / Re: performance of select record
« Last post by PxPlus on September 05, 2023, 10:31:46 AM »Just a side note.
As Stephane stated the select does not attempt to determine the best key to use. It was designed for speed and therefore assumes the programmer will pre-identify which key would be optimal.
Having the system analyze a request such as a SELECT to determine the key to use is basically a waste of system resources. The programmer should know up front which key would be best so why have the system try and figure this out every time it hits the SELECT statement?
Its fine for a generic query system SELECT to figure out which key to use, but for a program it makes more sense for the programmer to state which key the system should use to assure consistent results.
To simplify this the system supports named keys so that the file/table can have its keys altered and the programmer will not need to adapt the code to different key numbers. For example if you want the access by name, then name the key something like "ByName" and opposed to key number 'nnn'.
As Stephane stated the select does not attempt to determine the best key to use. It was designed for speed and therefore assumes the programmer will pre-identify which key would be optimal.
Having the system analyze a request such as a SELECT to determine the key to use is basically a waste of system resources. The programmer should know up front which key would be best so why have the system try and figure this out every time it hits the SELECT statement?
Its fine for a generic query system SELECT to figure out which key to use, but for a program it makes more sense for the programmer to state which key the system should use to assure consistent results.
To simplify this the system supports named keys so that the file/table can have its keys altered and the programmer will not need to adapt the code to different key numbers. For example if you want the access by name, then name the key something like "ByName" and opposed to key number 'nnn'.
24
Wish List / Re: Weeknumbers in multiline-calendar
« Last post by PxPlus on September 05, 2023, 10:23:36 AM »Its possible we could look at this however the issue with week numbers is what is week 1.
Is it the week that contains Jan 1, the week with the first Monday (or Sunday) in the year...
Different systems use different starting weeks.
Is it the week that contains Jan 1, the week with the first Monday (or Sunday) in the year...
Different systems use different starting weeks.
25
Wish List / Weeknumbers in multiline-calendar
« Last post by koenv on September 05, 2023, 09:59:48 AM »Would it be possible in the future to add weeknumbers to the calendar you get add to multilines, just like in Outlook? See attachment for example.
26
Programming / Re: Menu Bar Height and Font
« Last post by EVa on August 31, 2023, 03:46:29 AM »AFAIK, the menu appearance is a global (Windows) setting. You used to be able to change the menu font size in the Control Panel, under Appearance and Personalization, Display, but they have removed that item (Display) in more recent Windows versions. There's a 'System Font Size Changer' tool that still allows you to change the menu size though.
27
Programming / Menu Bar Height and Font
« Last post by steezware on August 29, 2023, 05:02:25 PM »I have menu bars defined for some Nomads panels and was wondering if it is possible to modify the size (height) of the menu bar or the font/size that it uses. Maybe increasing the font size would automatically change the menu bar height - that would be nice.
After digging around I couldn't find an INI file override or an 'Option' on-the-fly action that changes the menu bar height/font.
Any suggestions? Thx!
After digging around I couldn't find an INI file override or an 'Option' on-the-fly action that changes the menu bar height/font.
Any suggestions? Thx!
28
Programming / Re: performance of select record
« Last post by Stéphane Devouard on August 28, 2023, 07:16:53 AM »Thomas
This is an incorrect assumption. ProvideX SELECT is *not* SQL SELECT
You are right about SQL SELECT where the SQL engine chooses the best possible path to get to the data based on various criteria including the WHERE clause -- and it will be fast as long as you have indexed the columns on which you're selecting.
ProvideX SELECT is some syntactic sugar which allows you to easily code a file read loop
You can use a file channel or a file name. If you use the latter, the file will be closed after the last NEXT RECORD iteration
However :
- You must select yourself the best KNO to access the data. ProvideX won't do it for you
- If you use a file channel, the SELECT will start the loop at the current cursor position in the file, unless you use the BEGIN clause to specify the first key to read (this is the same as the Cobol START statement)
- Adding a WHERE allows ProvideX to execute the logic inside the SELECT/NEXT RECORD loop for only the records that match the conditions. Basically the IFs are done at the C-level therefore they are faster. If you don't specify a WHERE then the loop will be executed for all the record between the BEGIN (if any) and END (if any) clauses
Hope this helps
As it knows all the keys I'm interested in including all conditions it should be much faster than any programmed logic.
This is an incorrect assumption. ProvideX SELECT is *not* SQL SELECT
You are right about SQL SELECT where the SQL engine chooses the best possible path to get to the data based on various criteria including the WHERE clause -- and it will be fast as long as you have indexed the columns on which you're selecting.
ProvideX SELECT is some syntactic sugar which allows you to easily code a file read loop
You can use a file channel or a file name. If you use the latter, the file will be closed after the last NEXT RECORD iteration
However :
- You must select yourself the best KNO to access the data. ProvideX won't do it for you
- If you use a file channel, the SELECT will start the loop at the current cursor position in the file, unless you use the BEGIN clause to specify the first key to read (this is the same as the Cobol START statement)
- Adding a WHERE allows ProvideX to execute the logic inside the SELECT/NEXT RECORD loop for only the records that match the conditions. Basically the IFs are done at the C-level therefore they are faster. If you don't specify a WHERE then the loop will be executed for all the record between the BEGIN (if any) and END (if any) clauses
Hope this helps
29
Programming / Re: performance of select record
« Last post by PxPlus on August 24, 2023, 01:18:58 PM »Not certain how you ran your test but I just did the following:
-}list
0010 OPEN (1,IOL=*)"bigfile"
0020 LET rd=0,sel=0
0030 LET x=TMR(0)
0040 READ (1,END=0070)
0050 rd++
0060 GOTO 0040
0070 PRINT TMR(0),rd
0080 CLOSE (1)
0090 LET x=TMR(0)
0100 SELECT * FROM "bigfile"
0110 sel++
0120 NEXT RECORD
0130 PRINT TMR(0),sel
-}run
1.241 114697
1.089 114697
-}run
1.245 114697
1.088 114697
-}run
1.237 114697
1.087 114697
As you can see the SELECT was faster even considering the SELECT timing included the file open/close..
-}list
0010 OPEN (1,IOL=*)"bigfile"
0020 LET rd=0,sel=0
0030 LET x=TMR(0)
0040 READ (1,END=0070)
0050 rd++
0060 GOTO 0040
0070 PRINT TMR(0),rd
0080 CLOSE (1)
0090 LET x=TMR(0)
0100 SELECT * FROM "bigfile"
0110 sel++
0120 NEXT RECORD
0130 PRINT TMR(0),sel
-}run
1.241 114697
1.089 114697
-}run
1.245 114697
1.088 114697
-}run
1.237 114697
1.087 114697
As you can see the SELECT was faster even considering the SELECT timing included the file open/close..
30
Programming / Re: performance of select record
« Last post by Jim Morton on August 24, 2023, 11:16:03 AM »In your read loop were you using "read record" or an iolist?
Just making sure you are comparing apples to apples.
I have noticed that read/select record into a string template is a bit slower than read/select using an iolist.
Just making sure you are comparing apples to apples.
I have noticed that read/select record into a string template is a bit slower than read/select using an iolist.