Здравствуйте, mihailik, Вы писали:

M>А думаешь сколько они здесь могут заработать? Может им и нет смысла отвлекаться на Россию, Украину и т.п.

Ну, а тогда, что они пыжатся? Показухи то вон сколько... Кстати, в Украине все не так запущено как у нас (по слухам).

M>А на рекламу Микрософта "здесь" деньги и не нужны. И так все на нём работают.

Там тоже все. Но тем не менее Др.Добс и т.п. забиты их рекламой.

Можно и с другой стороны подойти. На толп использующих Яву и другие продуктв Сана у нас вроде нет. Но и они тоже в рекламу денег здесь не вкладывают.


M>Ну, права потребителей в этом случае — вопрос скользкий. Вон в Америке они судились-судились, и обломались... Трудно сказать, где заканчиваются права и начинается демагогия. Я не шарю

Ну, с такими бабками можно судиться с кем хочешь.

Здравствуйте, VladD2, Вы писали:

VD>Можно и с другой стороны подойти. На толп использующих Яву и другие продуктв Сана у нас вроде нет. Но и они тоже в рекламу денег здесь не вкладывают.

В данный момент у представительства Сана очень четкая политика — в России продают только железо.

Здравствуйте, mihailik, Вы писали:

M>Значит на .NET теперь простой клиент-сервер нельзя делать? Только "трёхзвенку"?

Можно, но только ADO.NET не очень хорошо для этого подходит.

M>>Значит на .NET теперь простой клиент-сервер нельзя делать? Только "трёхзвенку"?

AVK>Можно, но только ADO.NET не очень хорошо для этого подходит.

Пэчально
Теперь придётся исправлять кое-какие свои формы.

Я-то думал, что для скорости лучше использовать свой отдельный SqlConnection, а не те ADODB.Recordset'ы, которые мне мне внешнее приложение отдаёт.

M>>Значит на .NET теперь простой клиент-сервер нельзя делать? Только "трёхзвенку"?

VD>Всю логику работы с данными запициваешь в отдельную длл-ку. А так можно и в двухзвенке, а можно и в трехзвенке использовать.

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

M>>А думаешь сколько они здесь могут заработать? Может им и нет смысла отвлекаться на Россию, Украину и т.п.

VD>Ну, а тогда, что они пыжатся? Показухи то вон сколько... Кстати, в Украине все не так запущено как у нас (по слухам).

Чёрт его знает, что такое "запущено". Денег они здесь явно почти не зарабатывают.

M>>А на рекламу Микрософта "здесь" деньги и не нужны. И так все на нём работают.

VD>Там тоже все. Но тем не менее Др.Добс и т.п. забиты их рекламой.

Разная ситуация, разные методы, что ж тут странного?

VD>Можно и с другой стороны подойти. На толп использующих Яву и другие продуктв Сана у нас вроде нет. Но и они тоже в рекламу денег здесь не вкладывают.

Мне кажется, вкладывать у нас деньги в рекламу software практически нерентабельно. Какой смысл, если всё равно легально никто не купит?

M>>Значит на .NET теперь простой клиент-сервер нельзя делать? Только "трёхзвенку"?

AVK>Можно, но только ADO.NET не очень хорошо для этого подходит.

Пэчально
Теперь придётся исправлять кое-какие свои формы.

Я-то думал, что для скорости лучше использовать свой отдельный SqlConnection, а не те ADODB.Recordset'ы, которые мне мне внешнее приложение отдаёт.

M>>Значит на .NET теперь простой клиент-сервер нельзя делать? Только "трёхзвенку"?

VD>Всю логику работы с данными запициваешь в отдельную длл-ку. А так можно и в двухзвенке, а можно и в трехзвенке использовать.

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

M>>А думаешь сколько они здесь могут заработать? Может им и нет смысла отвлекаться на Россию, Украину и т.п.

VD>Ну, а тогда, что они пыжатся? Показухи то вон сколько... Кстати, в Украине все не так запущено как у нас (по слухам).

Чёрт его знает, что такое "запущено". Денег они здесь явно почти не зарабатывают.

M>>А на рекламу Микрософта "здесь" деньги и не нужны. И так все на нём работают.

VD>Там тоже все. Но тем не менее Др.Добс и т.п. забиты их рекламой.

Разная ситуация, разные методы, что ж тут странного?

VD>Можно и с другой стороны подойти. На толп использующих Яву и другие продуктв Сана у нас вроде нет. Но и они тоже в рекламу денег здесь не вкладывают.

Мне кажется, вкладывать у нас деньги в рекламу software практически нерентабельно. Какой смысл, если всё равно легально никто не купит?

Здравствуйте, mihailik, Вы писали:

M>Разная ситуация, разные методы, что ж тут странного?

С их влиянием и капиталом ситуацию можно создавать самим.

Здравствуйте, mihailik, Вы писали:

M>Тут вечно "план горит", приходится забивать на архитектуру и быстро клепать формы.

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

M>>Разная ситуация, разные методы, что ж тут странного?

VD>С их влиянием и капиталом ситуацию можно создавать самим.

Возможно, именно они её и создают?


Вообще да, рыночная стратегия Микрософта в СССР выглядит странновато. Только кто же её проанализирует, грамотно разберётся, хотя бы в самых общих чертах? Что-то некому

Как в наших условиях Микрософт может получить наибольшую прибыль? И настолько ли она "наибольшая", чтобы тратить деньги на серьёзный анализ и стратегию?

Конечно, они могут кинуть несколько миллиардов на развитие рынка, скажем, в России. Вместо того, чтобы потратить их на разработки, на выпуск Yukon, Longhorn и прочих дорогих игрушек. А стоит ли оно того?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, DemAS, Вы писали:

AVK>>>Лучше этого не делать
DAS>> Что не делать ?
DAS>> Как я не делать ? Или вообще ЭТО не делать ? А как тогда ?
DAS>> Краткость конечно искра таланту, но хотелось бы поподробнее

VD>Сестра.

VD>Не делать один коннект. Коннекты кешируются и скорость их создания и открытия очень высокая (на нее можно забить), а вот проблем от одного коннекта будет море. Это даже не коннект в старом АДО. Тут даже нельзя выполнить двух параллельных запросов.

Работал с ADO постепенно хочу перейти на ADO.NET. У меня всегда был один коннект и много рекордсетов! Неужели и вправду нежелательно в ADO.NET делать один Connect? Какие проблемы будут? Можно подробнее?

Здравствуйте, Nrisimhadev, Вы писали:

N>Работал с ADO постепенно хочу перейти на ADO.NET. У меня всегда был один коннект и много рекордсетов! Неужели и вправду нежелательно в ADO.NET делать один Connect? Какие проблемы будут? Можно подробнее?

ADO эмулировало это поведение. Реально конектов было много.

В будущем обещают и для АДО.НЭТ сделать такое же поведение. Но пока коннекты нужно плодить если нужно параллельный доступ к БД.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Nrisimhadev, Вы писали:

N>>Работал с ADO постепенно хочу перейти на ADO.NET. У меня всегда был один коннект и много рекордсетов! Неужели и вправду нежелательно в ADO.NET делать один Connect? Какие проблемы будут? Можно подробнее?

VD>ADO эмулировало это поведение. Реально конектов было много.

VD>В будущем обещают и для АДО.НЭТ сделать такое же поведение. Но пока коннекты нужно плодить если нужно параллельный доступ к БД.


Так если в каждой форме я осуществляю свой коннект, то если вдруг у меня меняется местоположение всей базы данных, то мне как-то придется св-ва всех коннектов переделывать? Как это проще сделать?

Здравствуйте, Nrisimhadev, Вы писали:

N>Так если в каждой форме я осуществляю свой коннект, то если вдруг у меня меняется местоположение всей базы данных, то мне как-то придется св-ва всех коннектов переделывать? Как это проще сделать?

Сроку соединения брать из конфигурационного файла.

Здравствуйте, DemAS, Вы писали:

Лучше хранить строку соединения и и использовать её вский раз при работе с БД, чтобы код был примерно такой

public static int FillDataTable(DataTable dt, string selectStr, string connectionString)
{
SqlCommand sqlComm = new SqlCommand();
SqlDataAdapter sqlDA = new SqlDataAdapter();
sqlDA.SelectCommand = sqlComm;
sqlComm.Connection = new SqlConnection(connectionString);
sqlComm.CommandText = selectStr;
sqlComm.Connection.Open();
try
{
return sqlDA.Fill(dt);
}
finally
{
sqlComm.Connection.Close();
}
}

Почитал нитку — руль!
С одним соединением возникнут проблемы при паралельном доступе — это факт.
Но если доступ не паралельный, то используй на здоровье одно соединение!
Я делал так: создавал отдельную библиотеку в ней статический класс, внутри класса есть private HashTable, в котором храняться открытые соединения, для каждого потока, обращающегося к классу. Соединения открываются при первом обращении потока к любому методу этого класса, а закрываются по DomainUnload или ProcessExit. В этом классе инкапсулированны все обращения к БД. Получается и конфликтов нет и соединение одно на поток. Можно их открывать/закрывать при выполнение конкретного действия, если держать открытыми неохота.

Удачи.

Здравствуйте, Dronkoff, Вы писали:

D>Почитал нитку — руль!
D>С одним соединением возникнут проблемы при паралельном доступе — это факт.
D>Но если доступ не паралельный, то используй на здоровье одно соединение!
D>Я делал так: создавал отдельную библиотеку в ней статический класс, внутри класса есть private HashTable, в котором храняться открытые соединения, для каждого потока, обращающегося к классу. Соединения открываются при первом обращении потока к любому методу этого класса, а закрываются по DomainUnload или ProcessExit. В этом классе инкапсулированны все обращения к БД. Получается и конфликтов нет и соединение одно на поток. Можно их открывать/закрывать при выполнение конкретного действия, если держать открытыми неохота.

D>Удачи.

Вы сами реализовали Connection Pool. Можно было просто открывать соединение каждый раз заново и driver/оболочка сама за вас делала бы connection pooling.

Здравствуйте, DemAS, Вы писали:

DAS>...
DAS>Как это реализовать правильнее. Необходимо, чтобы любая форма имела достум к этому экземпляру класса. Причем экземпляр этого класса всего один.

Если хочется — почему бы и не сделать. По этому поводу в четвертом номере RSDNа есть статья, но так как он еще не выложен в онлайн, могу только дать ссылку на соответствующий вспомогательный компонент — lsd.Database.

WBR,
XOR