<p>Using <a href="https://www.ncbi.nlm.nih.gov/books/NBK179288/" rel="nofollow noreferrer">Entrez Direct E-utils</a>, run the following command for your two examples:</p>
<pre><code>esearch -db SRA -query 'SRA030738 OR SRA030736' | efetch -format docsum | xtract -pattern DocumentSummary -element Runs | xtract -pattern Run -element Run@acc
</code></pre>
<p>(I know, it seems strange to run <code>xtract</code> twice, but the formatting on the plain xml output is dodgy. The first pass parsed out the unwanted <code>&amp;gt</code> or <code>&amp;lt</code> or <code>&amp;quot</code> characters. The second pass worked on the re-formatted <code>stdout</code>)</p>

CC BY-SA 4.0
2023-05-05T13:38:05.813Z
Perfect, the solution works. Thank you for taking the time to explain the double xtract 
Max_IT
CC BY-SA 4.0
2023-05-03T00:21:11.017Z
2023-05-03T00:21:11.017Z
user3479780
<p>@Max_IT and @user3479780 Thanks for bringing this issue to our attention. It has been fixed in EDirect 19.5, which is now available on our public ftp site (See installation instructions <a href="https://www.ncbi.nlm.nih.gov/books/NBK179288/" rel="nofollow noreferrer">here</a>). Please update your installation and try again.</p>
<p>The problem was that using capitalized <code>-db &quot;SRA&quot;</code> bypassed normalization of the record. This was easily solved within EDirect by lower-casing the <code>-db</code> argument value to make it case-insensitive.</p>
<p>Normalization unescapes the XML-encoded ExpXml and Runs field contents to integrate them as regular XML within the docsum in situ, before passing them to the user. Thus:</p>
<pre><code>efetch -db SRA -format docsum -id SRA030738,SRA030736 |
xtract -pattern DocumentSummary -element Run@acc
</code></pre>
<p>will now work properly, without the need for chaining two <code>xtract</code> commands together.</p>
<p>When creating structured records, NCBI internal software enforces conformation to the ASN.1 specification or XML document type definition. This is normally beneficial, blocking syntactically invalid records (and preventing new software bugs from silently corrupting production pipelines), but it limits the ability to add experimental structured data that is not (yet) in the spec.</p>
<p>Since <code>xtract</code> does not use a spec or DTD, it can find any element within the newly-unescaped contents by object name. (It still checks for properly-balanced opening and closing tags.)</p>
<p>Note also that you can skip the <code>esearch</code> step if you know the identifiers, and can instead pass them directly to <code>efetch</code> in an <code>-id</code> argument. For larger sets of identifiers, you can now pipe them from a file, one ID per line, without the need for an <code>epost</code> step.</p>
<p>EDirect has logic to split large lists into smaller chunks, sized appropriately for each database, and will internally loop through the fetch requests until all of the IDs have been processed, automatically retrying in the event of transient network or server failure.</p>

CC BY-SA 4.0
2023-05-09T20:06:41.787Z
Great, thank you, it sounds like this corrects the issue. The explanation on the usage of the new version is much appreciated.
Max_IT
CC BY-SA 4.0
2023-05-08T21:52:11.577Z
2023-05-08T21:52:11.577Z
vkkodali
<p>I am trying to download raw sequence data from the SRA database using the SRA toolkit (v.3.0.2). Unfortunately, the authors of the article I am reading gave SRA numbers (i.e. with the SRA prefix, not the SRR). This does not seem to work with the prefetch command:</p>
<p><code>prefetch --max-size 100000000 SRAxxxxxx -O downloads_SRAxxxxxx/</code></p>
<p>I ended up going on NCBI and manually finding the relevant SRR number for each sample; however, I was wondering if I could have done it programmatically. I appreciate your help.</p>
<p>Edit: Thank you for your comments, here are a couple of examples:</p>
<p>SRA030738 ; SRA030736 ;</p>
<p>Searching for them on SRA I found the SRR numbers, respectively:</p>
<p>SRR135604 ; SRR135602.</p>
<p>The paper is Hasan et al, 2012:  DOI: 10.1073/pnas.1207359109</p>

CC BY-SA 4.0
2023-04-29T14:03:27.243Z
Please [edit] your question and add a couple of example SRAs so we can test our solutions out without needing to go and look one up.
terdon
CC BY-SA 4.0
2023-04-29T23:19:50.620Z
`SRA` is an unusual prefix for an accession within SRA; I'm used to `SRR` (for runs), `SRX` (for experiements), `SRS` (for samples), and `SRP` (for projects). Can you please provide a link to the paper, or an alternative example?
gringer
CC BY-SA 4.0
2023-05-02T12:13:19.653Z
Can confirm, Supplementary Document #1 has codes starting with SRA. Searched first one in NCBI and I get two runs (starting with SRR...) from the same BioProject that seem to be correct.
Maybe the SRA-starting code is something mainly meant for the submitter? I wonder if there's a way to programmatically turn these codes into something more useful (BioProject code, run code...)
Laura
<sratoolkit>
SRA toolkit and SRA- prefix
# SRA toolkit and SRA- prefix

(Asked by: username_0 on 2023-04-28)

I am trying to download raw sequence data from the SRA database using the SRA toolkit (v.3.0.2). Unfortunately, the authors of the article I am reading gave SRA numbers (i.e. with the SRA prefix, not the SRR). This does not seem to work with the prefetch command:

`prefetch --max-size 100000000 SRAxxxxxx -O downloads_SRAxxxxxx/`

I ended up going on NCBI and manually finding the relevant SRR number for each sample; however, I was wondering if I could have done it programmatically. I appreciate your help.

Edit: Thank you for your comments, here are a couple of examples:

SRA030738 ; SRA030736 ;

Searching for them on SRA I found the SRR numbers, respectively:

SRR135604 ; SRR135602.

The paper is Hasan et al, 2012: DOI: 10.1073/pnas.1207359109

**Tags:** sratoolkit
> **Comments:**
> **username_1**: Please [edit] your question and add a couple of example SRAs so we can test our solutions out without needing to go and look one up.  
> **username_2**: `SRA` is an unusual prefix for an accession within SRA; I'm used to `SRR` (for runs), `SRX` (for experiements), `SRS` (for samples), and `SRP` (for projects). Can you please provide a link to the paper, or an alternative example?  
> **username_3**: Can confirm, Supplementary Document #1 has codes starting with SRA. Searched first one in NCBI and I get two runs (starting with SRR...) from the same BioProject that seem to be correct. Maybe the SRA-starting code is something mainly meant for the submitter? I wonder if there's a way to programmatically turn these codes into something more useful (BioProject code, run code...)  

---

## 2 answers

### Answer by username_4 on 2023-05-03. Score: 2 | Accepted answer

Using Entrez Direct E-utils, run the following command for your two examples:
esearch -db SRA -query 'SRA030738 OR SRA030736' | efetch -format docsum | xtract -pattern DocumentSummary -element Runs | xtract -pattern Run -element Run@acc

(I know, it seems strange to run xtract twice, but the formatting on the plain xml output is dodgy. The first pass parsed out the unwanted > or < or " characters. The second pass worked on the re-formatted stdout)

> **Comments:**
> **username_0**: Perfect, the solution works. Thank you for taking the time to explain the double xtract   

---

### Answer by username_5 on 2023-05-08. Score: 3

@Max_IT and @user3479780 Thanks for bringing this issue to our attention. It has been fixed in EDirect 19.5, which is now available on our public ftp site (See installation instructions here). Please update your installation and try again.
The problem was that using capitalized -db "SRA" bypassed normalization of the record. This was easily solved within EDirect by lower-casing the -db argument value to make it case-insensitive.
Normalization unescapes the XML-encoded ExpXml and Runs field contents to integrate them as regular XML within the docsum in situ, before passing them to the user. Thus:
efetch -db SRA -format docsum -id SRA030738,SRA030736 |
xtract -pattern DocumentSummary -element Run@acc

will now work properly, without the need for chaining two xtract commands together.
When creating structured records, NCBI internal software enforces conformation to the ASN.1 specification or XML document type definition. This is normally beneficial, blocking syntactically invalid records (and preventing new software bugs from silently corrupting production pipelines), but it limits the ability to add experimental structured data that is not (yet) in the spec.
Since xtract does not use a spec or DTD, it can find any element within the newly-unescaped contents by object name. (It still checks for properly-balanced opening and closing tags.)
Note also that you can skip the esearch step if you know the identifiers, and can instead pass them directly to efetch in an -id argument. For larger sets of identifiers, you can now pipe them from a file, one ID per line, without the need for an epost step.
EDirect has logic to split large lists into smaller chunks, sized appropriately for each database, and will internally loop through the fetch requests until all of the IDs have been processed, automatically retrying in the event of transient network or server failure.

> **Comments:**
> **username_0**: Great, thank you, it sounds like this corrects the issue. The explanation on the usage of the new version is much appreciated.  

---

