svd71

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

По bluetoth. Регистрируется приемник звука на компе.

Люди может я чегото не понимаю, но AndroidStudio тот же Eclipse, но с выкинутыми пакетами. Я так же в нем и для Java использую и для C/C++. И использую remote control который вроде бы для PHP создан.

Пробовал читать файл по 1000 строк (каждый раз приходится его открывать), естественно, в 30 сек оно не укладывается...

Таки вещи делаются через AJAX. Файл открывается на сервере и в браузер клиента пересылается инфа о количестве строк. Далее клиент позылает через AJAX короткие задания: занести в базу строки с 1 по 10. Даже при большом файле на короткие операции не такие уж длинное время требуется. После выполнения этоко маленького куска сервер через AJAX сообщает результат операции: успешно внесено, ошибка в строке NNN или что то еще.

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

А есть ли смысл для вас разбивать на разные Activiti? Может проще обходится без Intent и вести обработку в одном Java-классе, меняя только форму layout по требованию.

Классы позволяют проводить раширение дочерних элементов только в функционале классов. Интерфейся позволяют также раширять функциональность, но для любых классов. В этом то и главное отличие: Классы можно раширять "вертикально" (каждый потомок может расширить класс), итерфейсы позволяют раширять классы "горизонтально"(интерфейс можно имплементировать в любом классе, даже не имеющими общие предков).

Все зависит как вы собираетесь мигать лампочками.

Дешевый вот такой вариант. Схемы, прошивки и прочее есть на сайте. Выльется в $25.
Самый дешевый вариант вот этот. Обойдется гдето в $10.

При наличии любого контроллера AVR можно мигать лампочками непосредственно с компа.

Табурет. И при этом спину стараться держать прямо.
Иначе к 30 годам можно превратиться в вопросительный знак.

это зависит, какую цельвы ставите. Die() останавливает выполение всех скриптов в запросе с выводом сообщения. trigger_error переводит ошибку на какую либо обработку (напрмер на запись в лог-файл или отправку сообщения администратору).

Но оба варианта полохи, если не пользоваться PDO.

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

procedure TForm1.OnCklickFrom2(Sender: TObject);
begin
  Caption := TComponent(Sender).Name;
end;

procedure TForm1.FormCreate(Sender: TObject);
var
  Frm2 : TForm2;
begin
  Frm2 := TForm2.Crete(Application);
  Frm2.OnClick := Self.OnCklickFrom2;
  Frm2.Button1.OnClick := Self.OnCklickFrom2;
end;

Подвох в том что не видно разницы в двух переменных типа
echo $VAR ;
echo $VARLOG;
во втором варианте что именно имеется ввиду: отдельная переменная $VARLOG или перевенная $VAR и за ней следом выдавать LOG.

что за операционка установлена?
Судя по описанию, похоже было бы на то, что не разрешен IP_Forwarding, если это дело под Raspbian. Так же не мешало бы убедиться, выделяет ли клиенту IP и с какими параметрами.

ПС: я подключил к WiFi-роутеру.

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

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

Замечания @sebres очень даже имеют место. Многие СУБД конструируются на оптимальную работу именно с числовыми полями целого типа (хотя некоторые и позволяют использовать при желании в качестве ключа так называемый GUID - именно символьного типа). Сомневаюсь, что например MySQL имеет оптимизацию при работе с целочисленным типом: достаточно посмотреть на представление его целочисленных данных в таблице - они представлены в виде текста, а не конвертированы в 8 или 16 байтовое значение. Соотвествено сервер либо сам проводит посимвольное сравнение, либо предварительно конвертирует значение в "истинный", машинный int, что тоже сказывается на скорости. Вывод: нужно узнать, что производительней использовать для вашей СУБД.

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

Попробуйте тут почитать.

Вы правильно начали рассуждать, но не правильно закончили. Первичный ключ может состоять из нескольких полей. Только все поля должны быть NOT NULL.

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