You have a 0 / 1 column indexed?
Oh no.
That goes against recommendations. You're only supposed to index columns that have a lot of variability. That would be like indexing the word "the" in the back of a book. Because "the" appears so many times, it's faster to go word by word in the book than to flip back and forth between finding a location in the index and then going to the value. If you do an RBDefine of the table and click on the index, look at the Duplication Factor. A value of 1 means that values in the column are unique and make a good candidate for an index. The higher the number, the more "inefficient" the index is.
Thanks for that nicely succinct exposition!
I have been using R:Base since 1985 which gives me the possibly ridiculous idea that I can occasionally contribute but, at this stage, I only use R:Base to run my small business. It and the databases I created for customers in the past were going to be relatively small - '0,000s of rows rather than '00,000s. - and that and the nature of the databases may have colored my impression that keys/indexes were not worth the overhead on small databases. (RAM is good.) And yes, it could have been my poor implementation.
If Doug wanted to select by a particular date, he would need to read all the values but he needs to know if something was printed or not and that is binary so it seems to me it is crying for a 0 or 1.
Nicky
I'm with you -- since 99% of the time I'm interested in just the date portion of a DateTime, and it's a pain to always have to do a DEXTRACT on it, I usually split them into two columns also. I've never indexed a DateTime
Karen
--On Friday, June 20, 2025 at 11:48:45 AM CDT, 'Daniel Goldberg' via RBASE-L <[email protected]> wrote:
Sorry did not see the original email. Guess I needed to start from the beginning lol
I have a column called “prted” with integer of 0(default) or 1 in my table to specify if the item has been printed. When indexed works fast and takes little space. So I am doing similar to what Karen says.
A little off topic but in my experience using datetime column types(even indexed) are slow with large datasets. I usually create two columns, one for date and one for time.
Dan Goldberg
From: 'Karen Tellef' via RBASE-L <[email protected]>
Sent: Friday, June 20, 2025 7:58 AM
To: 'Daniel Goldberg' via RBASE-L <[email protected]>
Subject: Re: [EXTERNAL] Re: [RBASE-L] - Speeding up SELECT WHERE ColName IS NULL
But you're missing Doug's problem, Dan. In order to populate the temp table, he would have to say "where Datecol is null", because those are the records that haven't been printed yet. And Doug is saying that the "is null" is really slow
Karen
On Friday, June 20, 2025 at 09:53:20 AM CDT, 'Daniel Goldberg' via RBASE-L <[email protected]> wrote:
For my warehouse team, i create a temp table, open a form, and they double click or type in the part#s they want to print. Then the labels print based on the temp table.
No extra columns for your permanent tables and super fast.
Dan Goldberg
From: [email protected] <[email protected]> On Behalf Of Doug Hamilton
Sent: Friday, June 20, 2025 7:46 AM
To: [email protected]
Subject: [EXTERNAL] Re: [RBASE-L] - Speeding up SELECT WHERE ColName IS NULL
That would work, Buddy. Remember this column is not indexed, so the questions becomes:
What SELECTs multiple rows faster - a specific value or a null value?
Which is what Nicky's approach was asking.
DougOn 6/18/2025 4:30 PM, 'Buddy Walker' via RBASE-L wrote:
Doug
What I have done in the past was set the default value to some off the date like 12/31/1899 then print your labels where the date = 12/31/1899
Buddy
Sent from my iPhone
On Jun 18, 2025, at 4:41 PM, 'Karen Tellef' via RBASE-L <[email protected]> wrote:
Nick: His LabelsPrintedDTS field is a DATETIME or DATE, as far as I can tell
Karen
On Wednesday, June 18, 2025 at 03:36:00 PM CDT, 'Nicky Avery' via RBASE-L <[email protected]> wrote:
On Wednesday, June 18, 2025 at 02:31:55 PM CDT, Doug Hamilton <[email protected]> wrote:
Labels to be printed are selected WHERE LabelsPrintedDTS IS NULL.
Doug, when you create a new order, had you tried assigning a default value of 0 to LabelsPrintedDTS rather than no value? Once printed, you can change it to 1. This way you search on ... WHERE LabelsPrintedDTS = 0 rather than NULL.
Nicky
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visithttps://groups.google.com/d/msgid/rbase-l/dedc6469-0161-4ea0-b20d-c43b8e7a3e4e%40wwavs.com
.
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/893739093.98776.1750279295341%40mail.yahoo.com.--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/114B88D7-E622-451B-9415-F9CB7C27413C%40comcast.net.
Virus-free.www.avast.com
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/fd90a573-442a-44eb-94af-16bfefaaea4c%40wi.rr.com.--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/BY3PR19MB502744F408B9A21959DBB452D47CA%40BY3PR19MB5027.namprd19.prod.outlook.com.--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/1953759253.630007.1750431450360%40mail.yahoo.com.--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/BY3PR19MB5027B709E7D56D845D281BD5D47CA%40BY3PR19MB5027.namprd19.prod.outlook.com.
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/1742115404.686573.1750440060878%40mail.yahoo.com.
--
For group guidelines, visit http://www.rbase.com/support/usersgroup_guidelines.php
---
You received this message because you are subscribed to the Google Groups "RBASE-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/rbase-l/1ea0d634-5e45-44f8-8253-7b859eb462a3%40wwavs.com.
