The simplest variant of this could be:
```dataview
TABLE file.ctime as "Date created", file.size as Size
WHERE case_number = this.case_number
SORT file.ctime
```
This requires that your hub-page also has that unique case_number. If you’d want to exclude the hub page from the result you could either use a different name for this variable in the hub page, or exclude the current file from the result. In the next query we do both (just to save a little space, but you can choose either variant):
```dataview
TABLE file.ctime as "Date created", file.size as Size
WHERE case_number = this.hub_case_number
AND file != this.file
SORT file.ctime
```
On a sidenote, I’m an advocate for not relying on the creation date of files as my experience is that it can be changed to easily when syncing, backup/restore, copying, …, so I always set the date property to be the day of creation from my templates (and use the YYYY-MM-DD format). This allows for the use of file.day in dataview queries, and is in my opinion a better option. file.day gets its value either from a properly formatted date within the file name, or the date field of that file.
Your query would then look like:
```dataview
TABLE file.day as "Date created", file.size as Size
WHERE case_number = this.case_number
AND file != this.file
SORT file.day
```
( or the other version using something like hub_case_number )
In either case, the main thing in all of these queries is that prefixing the variables with this. in a DQL query makes it look at the current file’s information instead of the files you’re querying on.