Access

Подстановка access: Мастер подстановок

Мастер подстановок

Чтобы создать подстановку для поля таблицы, проще всего использовать соответствующий мастер. Для этого нужно выбрать в качестве типа данных поля значение: Мастер подстановок. Опишем работу мастера на примере создания подстановки для поля Код студента в таблице Сессия.

Рис. 2.3. Столбец подстановки

1. На первом шаге мастер предлагает указать источник данных для столбца подстановки:

По умолчанию используется первый пункт. Поэтому, так как мы собираемся использовать в качестве источника данных таблицу Студенты, нужно просто активировать кнопку Далее.

2. Мастер просит указать таблицу или запрос, содержащие столбец подстановки. В списке таблиц нужно выбрать таблицу Студенты и активировать кнопку Далее.

3. Затем нужно двойным щелчком мыши отобрать поля, используемые в подстановке:

Код студента, Фамилия и Имя. Последнее поле добавлено, чтобы иметь возможность различать студентов- однофамильцев.

4. Так как Код студента — ключевое поле, то Access автоматически выбирает его в качестве источника данных (присоединенного столбца) для поля подстановки. На этом шаге можно изменить ширину полей, используемых в подстановке, и указать, надо ли скрыть присоединенный столбец. Оставим без изменения установку по умолчанию: Скрыть ключевой столбец.

5. На последнем шаге зададим подпись для столбца подстановки Студент и нажмем кнопку Готово. Access попросит сохранить таблицу, и операция создания подстановки завершена.

Для просмотра полученных результатов перейдем в режим таблицы, щелкнув по кнопке Вид на панели инструментов. В первом столбце Студент вместо кодов студентов появятся их фамилии. Перейдем на последнюю, пустую запись таблицы, щелкнем по ячейке в поле

Студент, а затем по появившейся справа кнопке. Откроется список, содержащий фамилии и имена студентов (рис. 2.3). Если выбрать щелчком мыши одного из студентов, то в ячейке появится его фамилия, а в таблицу Сессия будет занесен его код.

В качестве источника данных для столбца подстановки может использоваться фиксированный список значений. Например, можно создать столбец подстановки для поля Оценка, указав на первом шаге работы мастера, что значения берутся не из таблицы, а из списка. Затем следует создать список, содержащий перечень возможных оценок: 2, 3, 4 и 5. После завершения создания столбца подстановки значения в поле Оценка можно будет не вводить с клавиатуры, а выбирать из списка. Чтобы изменить свойства поля подстановки, созданного с помощью мастера, нужно щелкнуть по ярлычку

Подстановка. На рис. 2.4 видны свойства поля Код Студента. Ниже дается их краткое описание:

  • Тип элемента управления — задается представление этого поля в форме.

  • Тип источника строк — указывается тип источника данных для поля. Им может быть таблица/запрос (по умолчанию) или список значений.

  • Источник строк — определяет источник данных. Если тип источника строк — таблица/запрос, то здесь указывается имя таблицы/запроса или инструкция SQL. Если тип источника строк — список значений, то указывается список элементов, разделяемых точкой с запятой.

  • Присоединенный столбец — указывается номер столбца, значения из которого заносятся в поле.

  • Число столбцов — задает число выводящихся столбцов.

  • Заглавия столбцов — выводятся (Да) или нет (Нет) в качестве заголовков столбцов имена полей или первые элементы списка значений.

  • Ширина столбцов — задается ширина выводимых столбцов (через точку с запятой). Чтобы скрыть столбец, нужно установить его ширину, равной 0.

  • Число строк списка — задает максимальное число строк, выводящихся в раскрывающемся списке.

  • Ширина списка — задает ширину раскрывающегося списка.

  • Ограничиться списком — указывает, что в поле вводятся только значения, принадлежащие списку (Да

    ), или разрешен ввод любых других значений (Нет). Access разрешит вводить в поле значения, не принадлежащие списку, лишь в том случае, если присоединенный столбец является первым отображаемым столбцом в списке.

Рис. 2.4. Свойства поля подстановки

Как корректно подтянуть информацию с помощью мастера подстановок в Microsoft Access? — Хабр Q&A

Я не отношусь к IT-специалистам, просто знаю, что можно автоматизировать процесс учета командировочных затрат с помощью Microsoft Access, и сейчас изучаю эту программу по книгам и иногда по видео на ютубе. Многое понятно, но столкнулась с такой сложностью, подскажите пжл как ее решить.
У меня несколько таблиц, и некоторые поля в таблицах подтянуты «мастером подстановок» и возникла проблема с их подтягиванием.
Таблица 1 «ФИО сотрудников» -Поля: «IDСотрудника» (ключевое) и «ФИОсотрудника»,
Таблица 2 «НомерКомандировки» — Поля: «IDномераКомандировки» (ключевое), «ФИОсотрудника» (подтянутое мастером из таблицы1) и «СтатусКомандировки» (логическое (галочка): если галочка стоит, то командировка закрыта, т.е. предоставлены все документы/если ее нет, т.е. не все документы предоставлены и командировка соответственно еще не закрыта).

Таблица 3 «КомандировочныеЗатраты» — Поля «IDзатрат» (ключевое), «ДатаЗатрат», «ФИОсотрудника» (подтянутое мастером из таблицы1), «ВидЗатрат»(выпадающий список: проживание, билеты, суточные, прочие), «НомерКомандировки» (подтянутое мастером из таблицы 2), «Сумма».
И когда подтягиваю мастером подстановок «НомерКомандировки» в таблице3, то выставляю условие, чтоб при подстановке этого номера так же были видны такие поля из Таблицы2: «IDномераКомандировки» (она нам и нужна), и дополнительно для информативности: «СтатусКоманидировок» (в убывающем порядке, чтоб первые шли командировки открытые) и «ФИОсотрудника» (по возрастанию, чтоб было видно ФИО сотрудника, по которому не закрыта командировка), данная дополнительная информация нужна, чтоб знать к какой по номеру командировке отнести возникшие затраты.

Но когда начинаю подтягивать, то в Поле «НомерКомандировки» в таблице3 раскрывается такая информация: «IDномераКомандировки» (то что нужно), но вместе с ним колонка «СтатусКомандировки» по которой указывается Вкл/Выкл, а нужно чтоб отображало галочку в конце списка, а сверху только незакрытые командировки, и самое главное по колонке «ФИОсотрудника» указывается «IDСотрудника», а не ФИО (хотя я выбирала именно поле «ФИОсотрудника», в итоге не понятно на кого из сотрудников относить данные затраты, т.к. виден только номер (сотрудников более 1 тыс. и помнить код каждого не реально), а постоянно заходить в другую таблицу и смотреть ФИО сотрудника и номер командировки тоже не выход, т.к. затрат очень много. Несколько раз убирала все связи и заново формировала мастер подстановок и все одно и тоже. Подскажите как можно корректно подтянуть в Таблицу3 в поле «НомерКомандировки» необходимую мне информацию. Заранее спасибо.

  • Вопрос задан
  • 128 просмотров

Подстановка значений переменных | Документация по сборке Cloud

Используйте замены в файле конфигурации сборки, чтобы заменить определенные переменные в время сборки.

Подстановки полезны для переменных, значение которых неизвестно до время сборки или повторно использовать существующий запрос на сборку с другой переменной ценности.

Cloud Build предоставляет встроенные замены, или вы можете определить свои собственные замены. Используйте замены в шагах вашей сборки и изображения для разрешения их значений во время сборки.

На этой странице объясняется, как использовать замены по умолчанию или определить свои собственные замены .

Использование замен по умолчанию

Cloud Build предоставляет следующие замены по умолчанию для всех сборки:

  • $PROJECT_ID : ID вашего облачного проекта
  • $BUILD_ID : ID вашей сборки
  • $PROJECT_NUMBER : номер вашего проекта
  • $LOCATION : регион, связанный с вашей сборкой

Cloud Build предоставляет следующие замены по умолчанию для сборок вызывается триггерами:

  • $TRIGGER_NAME : имя, связанное с вашим триггером
  • $COMMIT_SHA : идентификатор фиксации, связанный с вашей сборкой
  • $REVISION_ID : идентификатор фиксации, связанный с вашей сборкой
  • $SHORT_SHA : первые семь символов из COMMIT_SHA
  • $REPO_NAME : имя вашего репозитория
  • $BRANCH_NAME : название вашего филиала
  • $TAG_NAME : имя вашего тега
  • $REF_NAME
    : название вашей ветки или тег
  • $TRIGGER_BUILD_CONFIG_PATH : путь к файлу конфигурации сборки используется во время выполнения сборки; в противном случае пустая строка, если ваша сборка встроена в триггер или использует Dockerfile или Сборочный пакет .
Примечание: Оба $COMMIT_SHA и $REVISION_ID представляют связанный идентификатор фиксации с вашей сборкой. Доступна поддержка обеих замен.

Cloud Build предоставляет следующие настройки по умолчанию для GitHub. замены, доступные для триггеров запроса на вытягивание:

  • $_HEAD_BRANCH : головная ветвь запроса на вытягивание
  • $_BASE_BRANCH : базовая ветвь запроса на включение
  • $_HEAD_REPO_URL : URL-адрес головного репозитория запроса на вытягивание
  • $_PR_NUMBER : номер запроса на вытягивание

Если замена по умолчанию недоступна (например, в сборках без исходников, или со сборками, использующими источник хранилища), то вхождения отсутствующих переменная заменяется пустой строкой.

При запуске сборки с использованием сборок gcloud submit можно указать переменные, которые обычно поступают из триггерных сборок с --substitutions аргумент. Конкретно, вы можете вручную указать значения для:

  • $TRIGGER_NAME
  • $COMMIT_SHA
  • $REVISION_ID
  • $SHORT_SHA
  • $REPO_NAME
  • $BRANCH_NAME
  • $TAG_NAME
  • $REF_NAME
  • $TRIGGER_BUILD_CONFIG_PATH

Например, следующая команда использует TAG_NAME замена:

 gcloud builds submit --config=cloudbuild. yaml \
    --substitutions=TAG_NAME="тест"
 

В следующем примере используются замены по умолчанию $BUILD_ID , $PROJECT_ID , $PROJECT_NUMBER и $REVISION_ID .

YAML

 шагов:
# Использует этап сборки Ubuntu:
# для запуска сценария оболочки; и
# установить переменные env для его выполнения
- имя: «убунту»
  аргументы: ['bash', './myscript.sh']
  среда:
  - 'СТРОЙКА=$СТРОЙКА_ID'
  - 'PROJECT_ID=$PROJECT_ID'
  - 'PROJECT_NUMBER=$PROJECT_NUMBER'
  - 'REV=$REVISION_ID'
# Использует шаг сборки docker для создания образа с именем my-image
- имя: 'gcr.io/cloud-builders/docker'
  аргументы: ['сборка', '-t', 'gcr.io/$PROJECT_ID/my-image', '.']
# my-image помещается в Container Registry
изображений:
- 'gcr.io/$PROJECT_ID/мое изображение'
 

JSON

 {
  "шаги": [{
      "имя": "убунту",
      "аргументы": [
        "баш",
        ". /myscript.sh"
      ],
      "окружение": [
        "СТРОЙКА=$СТРОЙКА_ID",
        "ID_ПРОЕКТА=$ID_ПРОЕКТА",
        "PROJECT_NUMBER=$PROJECT_NUMBER",
        "REV=$REVISION_ID"
      ]
    }, {
      "name": "gcr.io/cloud-builders/docker",
      "args": ["сборка", "-t", "gcr.io/$PROJECT_ID/my-image", "."]
    }],
  "изображений": [
    "gcr.io/$PROJECT_ID/мое-изображение"
  ]
}
 

В приведенном ниже примере показан запрос на сборку с использованием docker шаг сборки образ, а затем отправляет образ в Container Registry, используя стандартное $PROJECT_ID замена:

В этом примере:

  • Запрос на сборку имеет один шаг сборки, который использует шаг сборки docker в gcr.io/cloud-builders для сборки образа Docker.
    • Поле args на шаге указывает аргументы, которые необходимо передать Команда docker , в данном случае build -t gcr. io/my-project/cb-demo-img. , будет вызван (после того, как $PROJECT_ID заменится вашим идентификатором проекта).
  • изображений поле содержит имя изображения. Если сборка прошла успешно, в результате образ помещается в Container Registry. Если образ не создается успешно по сборке, сборка завершится ошибкой.

YAML

 шагов:
- имя: gcr.io/cloud-builders/docker
  аргументы: ["сборка", "-t", "gcr.io/$PROJECT_ID/cb-demo-img", "."]
изображений:
- gcr.io/$PROJECT_ID/cb-demo-img
 

JSON

 {
  "шаги": [{
      "name": "gcr.io/cloud-builders/docker",
      "args": ["сборка", "-t", "gcr.io/$PROJECT_ID/cb-demo-img", "."]
    }],
  "изображений": [
    "gcr.io/$PROJECT_ID/cb-demo-img"
  ]
}
 

Использование пользовательских замен

Вы также можете определить свои собственные замены. Определяемые пользователем замены должны соответствовать следующим правилам:

  • Замены должны начинаться со знака подчеркивания ( _ ) и использовать только прописные буквы и цифры (с учетом регулярного выражения _[A-Z0-9_]+ ). Это предотвращает конфликты со встроенными заменами. Использовать выражение, начинающееся с $, вы должны использовать $$. Таким образом:
    • $FOO недействителен, поскольку не является встроенной заменой.
    • $$FOO возвращает литеральную строку $FOO .
  • Количество параметров ограничено 100 параметрами. Длина ключ параметра ограничен 100 байтами, а длина значения параметра ограничено 4000 байт.

Вы можете указывать переменные одним из двух способов: $_FOO или ${_FOO} :

  • Оба $_FOO и ${_FOO} дают значение 0FOO 0FOO 0FOO 0FOO 0FOO 0FOO 0FOO Однако ${} позволяет подстановке работать без окружающих пробелов, что позволяет замены, такие как ${_FOO}BAR .
  • $$ позволяет включить в шаблон буквальное значение $. Таким образом:
    • $_FOO оценивается как значение _FOO .
    • $$_FOO возвращает литеральную строку $_FOO .
    • $$$_FOO возвращает литеральную строку $ , за которой следует значение _FOO .

Чтобы использовать замены, используйте --substitutions аргумент в команде gcloud или указать их в конфигурационном файле.

В следующем примере показана конфигурация сборки с двумя определяемыми пользователем заменами. позвонил _NODE_VERSION_1 и _NODE_VERSION_2 :

YAML

 шаги:
- имя: 'gcr. io/cloud-builders/docker'
  аргументы: ['строить',
         '--сборка-аргумент',
         'node_version=${_NODE_VERSION_1}',
         '-т',
         'gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_1}',
         '.']
- имя: 'gcr.io/cloud-builders/docker'
  аргументы: ['строить',
         '--сборка-аргумент',
         'node_version=${_NODE_VERSION_2}',
         '-т',
         'gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_2}',
         '.']
замены:
    _NODE_VERSION_1: v6.9.1 # значение по умолчанию
    _NODE_VERSION_2: v6.9.2 # значение по умолчанию
изображений: [
    'gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_1}',
    'gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_2}'
]
 

JSON

 {
    "шаги": [{
        "name": "gcr.io/cloud-builders/docker",
        "аргументы": [
            "строить",
            "--сборка-аргумент",
            "версия_узла=${_NODE_VERSION_1}",
            "-т",
            "gcr. io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_1}",
            "."
        ]
    }, {
        "name": "gcr.io/cloud-builders/docker",
        "аргументы": [
            "строить",
            "--сборка-аргумент",
            "версия_узла=${_NODE_VERSION_2}",
            "-т",
            "gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_2}",
            "."
        ]
    }],
    «замены»: {
        "_NODE_VERSION_1": "v6.9.1"
        "_NODE_VERSION_1": "v6.9.2"
    },
    "изображений": [
        "gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_1}",
        "gcr.io/$PROJECT_ID/build-substitutions-nodejs-${_NODE_VERSION_2}"
    ]
}
 

Чтобы переопределить значение замены, указанное в файле конфигурации сборки, используйте флаг --substitutions в команде gcloud builds submit . Примечание что подстановки представляют собой сопоставление переменных со значениями, а не массивами или последовательности. Вы можете переопределить переменную подстановки по умолчанию значения кроме $PROJECT_ID и $BUILD_ID . Следующая команда переопределяет значение по умолчанию для _NODE_VERSION_1 , указанное в файле конфигурации сборки выше:

 gcloud builds submit --config=cloudbuild.yaml \
  --substitutions=_NODE_VERSION_1="v6.9.4",_NODE_VERSION_2="v6.9.5" .
 

По умолчанию сборка возвращает ошибку, если есть отсутствующая подстановочная переменная или отсутствующая подстановка. Однако вы можете установить параметр ALLOW_LOOSE , чтобы пропустить эту проверку.

Следующий фрагмент выводит «hello world» и определяет неиспользуемую замену. Поскольку установлена ​​опция замены ALLOW_LOOSE , сборка будет успешно, несмотря на отсутствующую замену.

YAML

 шагов:
- имя: «убунту»
  args: ['эхо', 'привет, мир']
замены:
    _SUB_VALUE: не используется
параметры:
    substitution_option: 'ALLOW_LOOSE'
 

JSON

 {
    "шаги": [
    {
        "имя": "убунту",
        "аргументы": [
            "эхо",
            "Привет, мир"
        ]
    }
    ],
    «замены»: {
        "_SUB_VALUE": "не используется"
},
    "параметры": {
        "substitution_option": "ALLOW_LOOSE"
    }
}
 

Если ваша сборка вызывается триггером, параметр ALLOW_LOOSE устанавливается по умолчанию. В этом случае ваша сборка не вернет ошибку, если есть отсутствующая подстановочная переменная или отсутствующая подстановка. Вы не можете переопределить параметр ALLOW_LOOSE для сборок, вызываемых триггерами.

Если опция ALLOW_LOOSE не указана, несовпадающие ключи в ваших заменах сопоставление или запрос на сборку приведет к ошибке. Например, если ваш запрос на сборку включает $_FOO и сопоставление замен не определяет _FOO , вы получит сообщение об ошибке после запуска вашей сборки или вызова триггера, если ваш триггер включает подстановочные переменные.

Следующие подстановочные переменные всегда содержат значение пустой строки по умолчанию, даже если вы не установили параметр ALLOW_LOOSE :

  • $REPO_NAME
  • $BRANCH_NAME
  • $TAG_NAME
  • $COMMIT_SHA
  • $SHORT_SHA

При определении подстановочной переменной вы не ограничены статическими строками. У вас также есть доступ к полезной нагрузке события, которое вызвало ваш триггер. Эти доступны как привязки полезной нагрузки. Вы также можете применить расширения параметров bash на переменные подстановки и сохранить полученную строку как новую замещающая переменная. Чтобы узнать больше, см. Использование привязок полезной нагрузки и расширений параметров bash в заменах.

Динамические замены

Вы можете ссылаться на значение другой переменной в пользовательском замену, установив для параметра dynamic_substitutions значение true в ваш файл конфигурации сборки. Если ваша сборка вызывается триггером, Поле dynamic_substitutions всегда имеет значение true и не требует быть указан в файле конфигурации сборки. Если ваша сборка вызывается вручную, вы должны установить для поля dynamic_substitutions значение true для параметра bash расширения, которые будут интерпретироваться при запуске вашей сборки.

В следующем файле конфигурации сборки показана переменная подстановки ${_IMAGE_NAME} , ссылающаяся на переменную, ${PROJECT_ID} . для поля dynamic_substitutions установлено значение true , поэтому ссылка применяется при вызове сборки вручную:

YAML

 шагов:
- имя: 'gcr.io/cloud-builders/docker'
  аргументы: ['сборка', '-t', '${_IMAGE_NAME}', '.']
замены:
    _IMAGE_NAME: 'gcr.io/${PROJECT_ID}/test-image'
параметры:
    dynamic_substitutions: правда
 

JSON

 {
   "шаги": [
      {
         "name": "gcr.io/cloud-builders/docker",
         "аргументы": [
            "строить",
            "-т",
            "${_IMAGE_NAME}",
            "."
         ]
      }
   ],
   «замены»: {
      "_IMAGE_NAME": "gcr. io/${PROJECT_ID}/test-image"
   },
   "параметры": {
      "динамические_замены": правда
   }
}
 

Дополнительные сведения см. в разделе Применение расширений параметров bash.

Что дальше

  • Узнайте, как использовать привязки полезной нагрузки и расширения параметров bash в замены.
  • Узнайте, как создать базовый файл конфигурации сборки.
  • Узнайте, как создавать триггеры сборки и управлять ими.
  • Узнайте, как запускать сборки вручную в Cloud Build.

Барьеры для доступа к опиоидной заместительной терапии, начала и удержания: опрос потребителей опиоидов, пациентов, находящихся на лечении, а также лечащих и нелечащих врачей

Сохранить цитату в файл

Формат: Резюме (текст)PubMedPMIDAbstract (текст)CSV

Добавить в коллекции

  • Создать новую коллекцию
  • Добавить в существующую коллекцию

Назовите свою коллекцию:

Имя должно содержать менее 100 символов

Выберите коллекцию:

Невозможно загрузить вашу коллекцию из-за ошибки
Повторите попытку

Добавить в мою библиографию

  • Моя библиография

Не удалось загрузить делегатов из-за ошибки
Повторите попытку

Ваш сохраненный поиск

Название сохраненного поиска:

Условия поиска:

Тестовые условия поиска

Электронная почта: (изменить)

Который день? Первое воскресеньеПервый понедельникПервый вторникПервая средаПервый четвергПервая пятницаПервая субботаПервый деньПервый будний день

Который день? ВоскресеньеПонедельникВторникСредаЧетвергПятницаСуббота

Формат отчета: SummarySummary (text)AbstractAbstract (text)PubMed

Отправить максимум: 1 шт. 5 шт. 10 шт. 20 шт. 50 шт. 100 шт. 200 шт.

Отправить, даже если нет новых результатов

Необязательный текст в электронном письме:

Создайте файл для внешнего программного обеспечения для управления цитированием

. 2011;17(1):44-54.

дои: 10.1159/000320576. Epub 2010 26 октября.

Хейно Стевер 1

принадлежность

  • 1 Факультет здравоохранения и социальной работы Университета прикладных наук, Франкфурт, Германия. [email protected]
  • PMID: 20975276
  • DOI: 10. 1159/000320576

Хейно Стевер. Европейский наркоман Res. 2011.

. 2011;17(1):44-54.

дои: 10.1159/000320576. Epub 2010 26 октября.

Автор

Хейно Стевер 1

принадлежность

  • 1 Факультет здравоохранения и социальной работы Университета прикладных наук, Франкфурт, Германия. [email protected]
  • PMID: 20975276
  • DOI: 10. 1159/000320576

Абстрактный

Предыстория/цели: Хотя число пациентов, проходящих опиоидную заместительную терапию (ОЗТ) в Германии в последние годы увеличилось, многие зависимые потребители опиоидов не получают лечения. Проект IMPROVE оценивал отношение и убеждения в отношении барьеров на пути к ОЗТ.

Методы: Данные были собраны у лиц с опиоидной зависимостью (с использованием анкет для самостоятельного заполнения), находящихся в настоящее время на лечении (n = 200) или не получающих лечение (n = 200), а также у врачей, аккредитованных для ОЗТ (с помощью компьютерного опроса по телефону), которые в настоящее время предоставляли ( n = 101) или не предоставляли ОЗТ (n = 51) из разных регионов Германии.

Полученные результаты: Основные результаты показали, что ОЗТ воспринималась врачами, пациентами и пользователями как ценная и эффективная, но доступ к ОЗТ и ее предоставление были недостаточными, особенно за пределами крупных городов.

Заключение: Эти выводы согласуются с национальными данными, свидетельствующими об усугубляющемся дисбалансе между спросом пациентов на лечение и количеством доступных врачей, аккредитованных для его предоставления. Многие врачи и пациенты не знали или не использовали терапевтические стратегии, которые могут помочь уменьшить злоупотребление и отклонение. Улучшение нормативно-правовой базы для ОЗТ и определение дополнительных источников поддержки и обучения будет стимулировать большее количество аккредитованных врачей к активному предоставлению лечения и, таким образом, поможет в полной мере реализовать преимущества доступных в настоящее время вариантов лечения.

Авторское право © 2010 S. Karger AG, Базель.

Похожие статьи

  • Структурные барьеры в контексте опиоидной заместительной терапии в Германии — опрос врачей первичного звена.

    Шульте Б., Шмидт К.С., Кунигк О., Шефер И., Фишер Б., Ведемейер Х., Реймер Дж. Шульте Б. и соавт. Subst Abuse Treat Prev Policy. 2013 22 июля; 8:26. дои: 10.1186/1747-597Х-8-26. Subst Abuse Treat Prev Policy. 2013. PMID: 23875627 Бесплатная статья ЧВК.

  • [Отношение и убеждения в отношении поддерживающей терапии опиоидами в Португалии: опрос врачей, пациентов и потребителей опиоидов].

    Гулан Х. Гулан Дж. Акта Мед Порт. 2013 сен-октябрь; 26(5):537-48. Epub 2013 31 октября. Акта Мед Порт. 2013. PMID: 24192093 Португальский.

  • Политика предоставления опиоидной фармакотерапии.

    Рэдклифф П., Паркс Т. Рэдклифф П. и др. Международная политика в отношении наркотиков. 2013 ноябрь;24(6):e6-10. doi: 10.1016/j.drugpo.2013.09.009. Epub 2013 10 октября. Международная политика в отношении наркотиков. 2013. PMID: 24183331 Аннотация недоступна.

  • [Опиоидная заместительная терапия во Франции: обзор врача].

    Мишель Л. Мишель Л. Энн Фарм о. 2009 сен; 67 (5): 369-73. doi: 10.1016/j.pharma.2009.05.006. Epub 2009 29 июля. Энн Фарм о. 2009. PMID: 19695374 Обзор. Французский.

  • Расширение масштабов поддерживающей терапии метадоном для заключенных с опиоидной зависимостью в Иране.

    Фарния М., Эбрахими Б., Шамс А., Замани С. Фарниа М. и соавт. Международная политика в отношении наркотиков. 2010 сен; 21 (5): 422-4. doi: 10.1016/j.drugpo.2010.03.008. Epub 2010 21 апр. Международная политика в отношении наркотиков. 2010. PMID: 20413287 Обзор.

Посмотреть все похожие статьи

Цитируется

  • Опыт пациентов в связи с изменениями в лечении метадоном во время первой волны COVID-19: национальное исследование, проводимое сообществом.

    Братья С., Палаев А., Саймон С., Коултер А., Стрихартц К., Войлс Н., Винсент Л. Братья С. и др. Harm Reduct J. 2023 9 марта; 20 (1): 31. дои: 10.1186/с12954-023-00756-3. Снижение вреда J. 2023. PMID: 36894968 Бесплатная статья ЧВК.

  • Сортировка по жизни: оценка важных для пациента показателей успеха в программе лечения расстройств, связанных с употреблением опиоидов (MOUD).

    Рид М.К., Смит К.Р., Чокко Ф., Хасс Р.В., Кокс А.Л., Келли Э.Л., Вайнштейн Л.С. Рид М.К. и др. Subst Abuse Treat Prev Policy. 2023 14 января; 18 (1): 4. doi: 10.1186/s13011-022-00510-1. Subst Abuse Treat Prev Policy. 2023. PMID: 36641478 Бесплатная статья ЧВК.

  • Барьеры лечения среди молодых людей, живущих с расстройствами, связанными с употреблением психоактивных веществ, в Тшване, Южная Африка.

    Няшану Т., Виссер М. Няшану Т. и соавт. Subst Abuse Treat Prev Policy. 2022 19 ноября; 17 (1): 75. doi: 10.1186/s13011-022-00501-2. Subst Abuse Treat Prev Policy. 2022. PMID: 36403019 Бесплатная статья ЧВК.

  • Включение результатов, о которых сообщают пациенты, для информирования о мерах эффективности лечения при расстройствах, связанных с употреблением опиоидов. Систематический обзор.

    Сэнгер Н., Панесар Б., Деннис М., Росик Т., Родригес М., Ловелл Э., Ян С., Батт М., Табане Л., Самаан З. Сангер Н. и др. Оценка отношения пациента к исходу. 2022 30 мая; 13:113-130. doi: 10.2147/PROM.S297699. Электронная коллекция 2022. Оценка отношения пациента к исходу. 2022. PMID: 35669100 Бесплатная статья ЧВК. Обзор.

  • Систематический обзор стратегий по улучшению надлежащего использования опиоидов и снижению расстройств, связанных с употреблением опиоидов, и смертности от рецептурных опиоидов.

    Фурлан А.Д., Карнид Н., Ирвин Э., Ван Эрд Д., Манхолл С., Ким Дж., Ли CMF, Хамад А., Махуд К., Макдональд С. Фурлан А.Д. и соавт. Может Джей Пейн. 2018 31 июля; 2 (1): 218-235. дои: 10.1080/24740527.2018.1479842. Электронная коллекция 2018. Может Джей Пейн.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *