"-- auto-generated definition -- No source text available"



I'm having an issue with seeing package/procedure/function source code for schemas other than the one I'm logged in with. Every time I try to see the source code for them I get the following text:

-- auto-generated definition
-- No source text available

I am using an Oracle connection with an account that has DBA privileges, and when using sql developer or sql*plus can see all source code for any object. I've synchronized all of my schemas, as well. Has anyone come across this issue, and is there any way to fix this, other than logging into each of the schemas directly to see the object source code?



Do you want to see sources for SYS or SYSTEM schema? Did you add it to the introspection scope? Did you invoke Forget cached schemas?
Thank you.


I have the same problem, when I try to check the code of an trigger datagrip retrieve me this message. 

-- auto-generated definition
-- No source text available

If I do the same steps within Rider, it works as it should retrieving me the code of the trigger. What is the point ?



Are you trying to retrieve source for a trigger which uses some functions from another schema?

Could you provide any sample DDL to reproduce?

Thank you.


There is a function withing the trigger, but they are on the same schema. 
By the way, I'm working with Oracle as well. 

create trigger TIA_VAN_SUPPLIER
after insert
for each row
VAN_PRC_REGISTERINSERTDELETE('supplierinserted', :new.SUPPLIERID, 'supplierid', :new.SUPPLIERID);



Same problem in DG in mac  10.12.6



Having same issue. Sometimes, especially for new functions in postgresql it shows:

-- auto-generated definition
-- No source text available

instead of source code. It somehow randomly may show source code (may be after restart or some time), but no workaround so far.

intellij IDEA 2017.2.5 macos 10.12 postgresql database.

This issue is reported by users across net, and no reaction from developers (

Really annoying thing.


Similar random isue as the previous post for me with postgresql.

I give the details :

  - At the end of this post you've got one of the stored postgresql function on which this bug occured.

  - There is no call from other functions in it.

  - I have two database connections : one on my test database, and one on my production database.

  - I usually never edit the source of this function in my production database, always from the test database.

  - "Suddenly", I mean after an event like upgrading phpstorm version or maybe something else, this bug occured on my test database. It never happened with the 2016 phpstorm release for me.

 - So I tried to edit the source of this function from my production database, while being connected to it, and it is ok.

 - I closed the connection to my production database and tried to edit the source of this function from it, and it is ok.

 - I have other "replicated" and "staging" version of this database, did the same test scenario and it's ok. So it looks like the bug is only on my test database, which is the one I usually edit this source from.

 - I tested this scenario with another function and got exactly the same results.

 - So, it look's like this bug takes effect on database connections that are used for edition of sources...but in my case it's not really that much random : I just can't edit anymore any stored postgresql function of this database.

 - I created a new connection on this database (so with the same parameters as the failing one), but got the same bug.

- Postgresql function :

CREATE FUNCTION get_dne_data (integer, integer) RETURNS record
    LANGUAGE plpgsql
AS $$
    output              RECORD;
    lid_contract         ALIAS FOR $1;
    contract_end_notice_length         ALIAS FOR $2;
    minimal_stop_date   DATE;
    last_payment_date   DATE;
    date_reengagement   DATE;
    months_to_debit     INTEGER;
    month_nbr           INTEGER;
    has_contract_12_months      BOOLEAN;
    amount              NUMERIC(10,2);
-- Détermination de la date minimale de réengagement
    SELECT (to_char(coalesce(c.date_reengagement, c.start_date)::date,
            + '13 months'::interval - '1 day'::interval)::date
      INTO minimal_stop_date
     FROM Contracts c
    WHERE c.id_contract = lid_contract;

-- Détermination du dernier payment réalisé
            WHEN r.is_active AND r.stop_date IS NULL THEN 'now'
            WHEN r.is_active AND r.sage_status = 'X_BEFORE_END' AND r.stop_date IS NOT NULL THEN r.stop_date
            ELSE r.stop_date
      INTO last_payment_date
     FROM contracts r
    WHERE r.id_contract = lid_contract;

-- Détermination du nombre de mois à payer
    SELECT count(accounting_date) INTO months_to_debit
     FROM bankcalendar
    WHERE accounting_date between last_payment_date + '1 day'::interval
                              and minimal_stop_date
      AND prelevement_type = 2;

-- On détermine si le contrat à plus de 12 mois
            when r.stop_date is not null and r.stop_date >= date('now') and age(date('now'), r.start_date) >= '1 year' then 't'
            when r.stop_date is not null and r.stop_date < date('now') and age(r.stop_date, r.start_date) >= '1 year' then 't'
            when r.stop_date is null and age(date('now'), r.start_date) >= '1 year' then 't'
            else 'f'
       end into has_contract_12_months
     FROM contracts r
    WHERE r.id_contract = lid_contract;

 -- Calcul de la date de réengagement
   SELECT r.date_reengagement INTO date_reengagement
     FROM contracts r
   WHERE r.id_contract = lid_contract;

   IF    (date_reengagement IS NOT NULL
      AND CURRENT_DATE < minimal_stop_date) THEN
      month_nbr := months_to_debit;
   ELSEIF (has_contract_12_months) THEN
      month_nbr := contract_end_notice_length;
      IF (months_to_debit > contract_end_notice_length) THEN
        month_nbr := months_to_debit;
        month_nbr := contract_end_notice_length;
      END IF;
   END IF;

-- month_nbr must be at least 2 months
   IF (month_nbr < 2) THEN
      month_nbr := contract_end_notice_length;
   END IF;

-- Calcul du montant de la mensualité du contrat
   SELECT st.amount INTO amount
    FROM Contracts ct, Subscriptions st
   WHERE ct.id_subscription = st.id_subscription
     AND ct.id_contract = lid_contract;

    SELECT DATE(DATE_TRUNC('MONTH', CURRENT_DATE + (month_nbr || ' MONTH')::interval) + '1 MONTH'::interval - '1 day'::interval),
      INTO output;
    RETURN output;



To be more precise : here is what I get when I right-click on "Jump to Editor" on this function :

-- auto-generated definition
create function get_dne_data(integer, integer)
language plpgsql
-- missing source code for get_dne_data


...and sorry the os version :

testp1@testp1-VirtualBox:~/httpd/htdocs/fdelahaye$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.2 LTS
Release:        16.04
Codename:       xenial


phpstorm build :


I was able to solve by going into the datasource's properties, options tab, then check the box for Introspect using JDBC metadata.  Then click the synchronize button in the database tool window.


As a temporary workaround one needs to invoke "Database tools -> Forget cached schemas" action to get up-to-date routines sources.


I can confirm the same issue with DataGrip 2018.3, forgetting cached schemas and using JDBC introspection does not help


Same issue with Datagrip 2019 3.2 on Oracle 12.2. Forgetting cached schemas and using JDBC introspection does not help.



DataGrip has no full Oracle 12 support at the moment.

Do you want to see sources for some internal routines?


vasily chernov to make it clear — I have experienced this problem with Oracle 11. Clearly it does not seem version dependent from my perspective.


@Asd, @Egor S.,

Could you e-mail me vasily.chernov@jetbrains.com full IDE & SQL logs for investigation?



Can't reproduce it on Oracle 12.2 after updating from Datagrip 2019 3.2 to DataGrip 2019.3.3. Build #DB-193.6494.42.


Can't reliably reproduce on DG 2020.1


Still the same problem at DataGrip 2020.2 with PostgreSQL... and there are no  "Database tools -> Forget cached schemas" available... how did you solve it?



It's better to use Diagnostic Refresh and send logs to DataGrip team for investigation. Read more about refresh in our blog post https://blog.jetbrains.com/datagrip/2020/10/15/datagrip-2020-3-eap-2/



Please sign in to leave a comment.