Delphi + SQL Server

Има ли някой тук да работи с тази база данни - SQL Server
Налага ми се (вече е решено отгоре) че ще заменяме Paradox с SQL Server 2000 Програмата ми естествено е сьздадена за Paradox и има много TTables TQueries TDfataSource Като премина кьм SQL ще се наложи да променя врьзките. Можете ли да ме посьветвате кой components да използвам да се свьржа с SQL?
Има ли някой от вас вече да е минал по този пьт?

Най-добре е да използваш ADO. Като функционалност те са доста близки до познатите ти TTable и TQuery. Разбира се, винаги има вариант да продължиш да ползваш BDE, тъй като през него също можеш да се вържеш към SQL Server, но ADO ще ти даде значително по-висока производителност.

BDE вече не се подьржа (от v 5.2) Идеята е да се махне и замени с нещо друго.И аз мислех за АДО.Програмата е на Delphi 2005 Win 32
Имам около 300 TTABLE and TQUERIES свьрзани с Paradox чрез БДЕ.

Май ще е ад Притеснявам се как ще работи програмата ако само заменя Paradox s SQL i TTable s ADOTable.

Убеден съм, че не би имал проблеми със ADO, стига да подходиш внимателно, и може би малко да преосмислиш дизайна на програмата си. Това което ме притеснява не е ADO и MS SQL Server (използвам ги от времето когато нямаше такива компоненти за Делфи), а ако съм разбрал правилно това: "300 TTABLE and TQUERIES" Това компоненти ли са?!? Или таблици и процедури? Ако са физически таблици - няма абсолютно никакъв проблем, дори да са и хиляди. Но ако са компоненти... Да не би да ти се налага в един и същи момент да отваряш стотина таблици? Ако не - защо не използваш максимум 10 DB компонента, и им заменяш SQL стринга динамично, в зависимост от необходимостта, или сменяш името на таблицата като "property" също динамично? Така мисля, че ще стане мноооого "по-леко" приложението ти, а и няма да "товариш" сървъра с отворени таблици.
Така или иначе, ще трябва да смениш всички TTable и TQuery компоненти с TADOQuery и TADOStoredProc. Не ти препоръчвам да използваш TADOTable при таблици, които имат повече от 100 записа - "тъпо" е да "теглиш" хиляди реда, заради визуализацията на един. Не зная, може би има и по-добри решения, но това което използвам е: един нов units, където като ресурсстрингове са записани всички използвани от мен заявки, например

resourcestring
SQL_CONTRACTS_DIARY = 'SELECT BATCH_DATE, INTERNAL_ID, RECORDS_COUNT, CORRECT_RECORDS_COUNT, INCORECT_RECORDS_COUNT
FROM CONTRACTS_DIARY WHERE BULSTAT=%s';

SQL_CONTRACTS_INCORRECT = 'SELECT BATCH_DATE, INTERNAL_ID, INCORECT_RECORDS_COUNT
FROM CONTRACTS_INCORRECT WHERE BULSTAT=%s';

SP_DAIRY_2004 = 'SP_DAIRY_2004'; // Съхранена процедура в SQL Server


Така в една от моите програмки имам над 400 такива контстантни стрингове.
Разбира се, използването им, и писането на такива заявки има смисъл, ако не използваш съхранени процедури в SQL сървъра. Те са за предпочитане.

След това там където ми трябва дадена заявка (използвам максимум 3 TADOQuery компонента, един TADOStoredProc и НИТО една TADOTable един в програмите си), динамично задавам заявките:

DM.ADOQuery.Active := False;
DM.ADOQuery.SQL.Clear;
DM.ADOQuery.SQL.Add(Format(CONTRACTS_INCORRECT, [sBULSTAT]));
DM.ADOQuery.Active := True; // или ExecSQL в зависимост от резултата


или при съхранена процедура

DM.ADOStoredProc.Active := False;
DM.ADOStoredProc.Connection := DM.ADOConnection;
DM.ADOStoredProc.ProcedureName := SP_DAIRY_2004;
DM.ADOStoredProc.Parameters.Clear;
DM.ADOStoredProc.Parameters.AddParameter;
DM.ADOStoredProc.Parameters.Items[0].Name := 'ID';
DM.ADOStoredProc.Parameters.Items[0].DataType := ftString;
DM.ADOStoredProc.Parameters.Items[0].Value := sBULSTAT;
DM.ADOStoredProc.Active := True;




На мен това ми помага, дотолкова, че не трябва да се ровя в 30 000 реда например, да търся къде бе този или онзи SQL стринг, не е небходимо да имам 10-ки компоненти, и т.н....
Но всеки си избира начин на работа - важното е резултата да е положителен

Мерси Ивко. Не сьм и очаквала толкова изчерпателен отговор

Положението е следното: Манажмента решава, че Парадокс трябва да се замени с SQL Server. Добре обаче програмата естествено в написана за Парадокс. Те ми казват (разбирай манажерите) - ще го направим в 2 етапа.
Пьрвият - минимална промяна на програмата и замяна на Парадокс с SQL Втората фаза - промяна на кода и оптимизация. Фаза 1 - около 6 месеца (след което клиента изплозва програмата докато трае фаза 2)

За TTables and TQueries - компоненти са.Знам трябва да ги заменя един по един. Повечето са сьздадени в самата форма не в отделен unit.

Твоята идея ми хареса и отделен unit и да викам заявките от всяка форма.Само че май ще се наложи да сьздам всички TADOQueries пак в сьотвените форми, а не в отеделна форма.

За TTables i TADOTAbles прав си че ако са голями няма смисьл от използване, обаче нали фаза 1 била само сменяне на база данни и май ще трябва да ги оставя до фаза 2.

Абе голяма работа се очертава, ама карай да вьрви на ми плащат

Единственото, което на този етап, мога да ти пожелая е УСПЕХ!
Наистина се очертава "яка" работа
Не ми е работа да давам акъл на "менаджери" дето не познавам, може да са и по-опитни от мен, но май ще е хубаво да преосмислят малко стратегията си.
Няма да е толкова лесно, няма да е само заместване на Парадокс със SQL..
Ако искат да извлекат максималните предимства на SQL сървър, ще трябва почти всички заявки към него да се прехвърлят на "съхранени" процедури, да използват тригери, и разни други "глезотии". Предимството е много голямо, едва ли е тук мястото, а и сега да ги изброявам, но:
- SQL сървъра, когато се използват съхранени процедури, при първото им стартиране, ако не се "форсирара" самия сървър, изготвя така наречения "план на изпълнение на заявката". След което "компилира" SQL заявката, и при следващото извикване на "съхранената процедура", използва този "план на изпълнение", в резултат на което изпълнението и е многократно по-бързо. А при използавене на TADOQueries където се задава стринга на изпълнение, това се върши всеки път, и се губи значително от бързодействието. Така че ако може нещо да бъде направено на "съхранената процедура", то се прави. Освен това, тя се намира на сървъра, и може по всяко време да се промени, така че не е необходимо да се прекомпилира отново приложението (Делфийското), за всяка една неотразяваща се на функционалността промяна на SQL заявка.
- Възможност за използването на вградени SQL функции, които за мнооого полезни, особенно при промяна на бизнес-логиката - виж по-горе какво е казано за "съхранените процедури"
- Възможност за използване на тригери. Улесняват живота в много случаи.

Така, че май ще трябва да вършите два пъти едно и също нещо. Дори май ще е по-тежко, защото следващия път, ако искате всичко да е като в "най-добрите практики", ще трябва да променяте и SQL базата, нейната структура, и т.н.
Ама ТЕ са ти "менаджери", а не аз, така че си ги слушай, че обикновено началниците не се радват, когато им дават акъл
Ако има нещо, дето може да ти помогнем - "свиркай", кой колкото и с каквото ще помага - нали за това са тези клубове

виж GExperts.
[линк]
Той се интегрира в елфито и върши такива работи, като подмяна не едни компоненти с други, като запазва максимално пропъртита и екшъни които съвпадат.

Но все пак препоръчвам да използваш BDE за връзка с MSSQL, независимо от някой малки проблеми (например работа с блобове), които се заобикалят. Така ще се преправя най- малко.