I found description of simple web server at free pascal documentation.
Example code uses two sockets: listenerSocket and connectionSocket. Why? I thought it should be enough one.
ListenerSocket := TTCPBlockSocket.Create;
ConnectionSocket := TTCPBlockSocket.Create;
ListenerSocket.CreateSocket;
ListenerSocket.setLinger(true,10);
ListenerSocket.bind('0.0.0.0','1500');
ListenerSocket.listen;
repeat
if ListenerSocket.canread(1000) then
begin
ConnectionSocket.Socket := ListenerSocket.accept;
AttendConnection(ConnectionSocket);
ConnectionSocket.CloseSocket;
end;
until false;
ListenerSocket.Free;
ConnectionSocket.Free;
Related
When I use DecoupledIO, it seems that it generates errors caused by Reference io is not fully initialized.
This is because I have to initialize Output, in this case, bits, and valid or ready(depending on flipped or not)
Let's assume that bits and valid is Output.
when I use following statement:
when(reset.toBool) {
bits := 0.U
valid := true.B
}
it generates error.
But when the initialize statement exist outside of when statement, it does not produce errors.
So, how to solve such initialization problems?
Do I always have to initialize such values outside of when statement although I want to put it inside when(reset.toBool) statement?
Even, the router example in the wiki page produces error even though I follow the guide described by unconnected wire section(this was due to the fact that all init statement exist inside when statement)
This is a good question but a little hard to explain. When you wrap the output initialization in the when(io.reset) it creates a edge case where the wire may not be initialized if reset is not been asserted. The easiest fix is to do both
bits := 0.U
valid := true.B
when(reset.toBool) {
bits := 0.U
valid := true.B
}
Last connect semantics will ensure that the reset and decoupled behavior is take precedence but that you will have covered the edge case. The chisel team is aware of this problem and looking for a more elegant situation. See Chisel Issue 703
So I can't get too specific, but I think what I can tell you will be enough to figure this out. First I'm using gorp to set things up and get the transaction. I am using the github.com/denisenkom/go-mssqldb driver.
Then I run through a series of operations and if of them fails I rollback and if all have success I commit. The problem is that it's only rolling back the statement that failed and not the rest of the operations. Am I wrong that this is not how that is suppose to work?
Here is some rough psudocode to give you a better idea of what I'm talking about:
trans,err := dbmap.Begin()
//assume all errors are received and checked before continuing
id := trans.Exec("insert thing") //successful, persists after rollback
thing := trans.Select("Select thing") //successful
trans.Exec("update other_thing with thing") //successful, persists after rollback
newthing := trans.Exec("insert new_thing with thing") //fails, rollsback
if err != nil{
trans.Rollback() //No errors
return
}
trans.Commit()
Am I wrong that that should rollback everything since dbmap.Begin()? Is this a bug in the driver implementation? Any and all help is GREATLY welcome. Thanks!
Update
Tested https://play.golang.org/p/0L3Vgk8C_F and it worked so I'm guessing that means it something to do with gorp. I'm using the v1 branch since this will be production soon and so stability is key. I'll be picking through it, but it looks like it's just wrapping it lightly.
Check you don't have autocomit enabled. Many command line tools, uis and even drivers enable it by default
According to this( I read just a few lines) https://technet.microsoft.com/en-us/library/ms187878(v=sql.105).aspx
autocommit seems to be ON by defauly, that leads me to conclusion that if the author of go-mssqldb didn't implement on/off for this feature its ON.
You can toggle it yourself just search for SET IMPLICIT_TRANSACTIONS
I'm trying to delete all the scene objects in the GLScene container and I use the following code snippet to do it, but for some unknown reasons it crashes raises the segmentation fault when I try to free the object.
I tried to debug line by line and it revealed that somehow container class of Glscene1.Objects[i] contains some inexplicable classes which has the '#2' class name. I 've tried to run through the very same code snippet w/o calling the Free method then there doesn't occur any abnormalitie, objects are not deleted but there is consistency in object class names.
for i := 0 to GLScene1.Objects.Count - 1 do
begin
if (not GLScene1.Objects[i].ClassNameIs('TGLCamera')) and
(not GLScene1.Objects[i].ClassNameIs('TGLLightSource')) and
(not GLScene1.Objects[i].ClassNameIs('TGLDummyCube')) and
(not GLScene1.Objects[i].ClassNameIs('TGLXYZGrid')) and
(not GLScene1.Objects[i].ClassNameIs('TGLSceneRootObject')) then
begin
// if GLScene1.Objects[i].Count > 0 then
// GLScene1.Objects[i].DeleteChildren;
GLScene1.Objects.Remove(GLScene1.Objects[i],false);
if GLScene1.Objects[i] <> nil then // I comment out these lines
GLScene1.Objects[i].free; // I comment out these lines
end;
end;
The most often mistake made is a try to delete GlFreeForm when there is still GLProxyObject that reffer to a parent GlFreeForm. So the best solution to clear scene is to set all GLProxyObject's MasterObject parameter to nil first. To avoid blocking objects it is advised to use single GLDummyCube (GLDummyCube1 in this example) as a root object for all other scene objects:
if Form1.GLDummyCube1.Count>0 then
begin
for I := (Form1.GLDummyCube1.Count-1) downto 0 do
begin
if (Form1.GLDummyCube1.Children[I].ClassNameIs('TGLProxyObject')) then
begin
TGLProxyObject(Form1.GLDummyCube1.Children[I]).MasterObject := nil;
end;
end;
while (Form1.GLDummyCube1.Count>0) do
begin
try
Form1.GLScene1.FindSceneObject(Form1.GLDummyCube1.Children[0].Name).Destroy;
except
//inform error, but I never had one
end;
end;
end;
I never had any problems with that code for a long 4 years of heavy usage, so feel free to use it.
this is a question similar to this one but with a different background.
Compiler: Delphi 2010, soon Delphi XE5.
I have built a nice application that manages data on a remote MySQL server through the ZEOS components.
Since the connection could fail and SQL be slow I have used the neat OmniThreadLibrary to create an SQL server watchdog and to offload a lot of "read only" tables loading to threads.
As of now I have three data modules manually created before the main form shows, each with their independent TZConnection and some TZReadOnlyQuery components linked to the same data module TZConnection. Each thread instantiates its related data module from within itself and then executes the queries.
The watchdog is working quite well, but I have some doubts about the second part, that is the "read only" tables thread. The queries work already but I have yet to use their results in the main application business code, where I have to insert and update data on other tables.
In my plans I get all these "read only" dataset read and loaded before the main application even connects to them (the whole inter-thread state machine is done already). In theory there should be no concurrency issue as the "read only" tables thread has finished its task and is now being idle.
But I don't know what happens if at this point I connect a control or another dataset / datasource / whatever from the main form to the idle-threaded data module.
Will I mess up because the main form TZSession is not the same of the threaded data module? Will I get rare & nasty access violations to be discovered ONLY after having delivered the application (of course!). Basically with what kind of confidence or precautions should I access a query component created in another thread, assuming only the main application does it and only for reading data? Is it even possible / healthy at all? Or am I missing some "best practices" way of doing it?
Thanks in advance.
I am going to post how I have done it. It'll be "terse" (it's still a monumental wall of text!) due to lack of time, if you find something being too obscure feel free to ask. I don't pretend to have written neither the best nor the quickest nor the best formatted code. Just use it as your starting point.
Short recap of the problem domain: having a software that "pre-opens" tables at startup using a thread. This lets the software stay responsive and even perform other non database related startup tasks.
I have tested this program for 1 month now and the database components used are enough to prove it's not just a "toy demo" ready to break as you add your 3rd dataset.
Ingredients:
As stated above: Delphi 2010+ (I am now running this in RAD Studio XE5 Ultimate) but could probably work with earlier versions. I just did not test them.
ZEOS library, 7 and upwards should work including the latest 7.2 alpha.
OmniThreadLibrary
In my case I also used JVCL but that's only because I needed some specific data source events the basic components don't offer.
IDE, non code portion
create 2 data modules that will host the database components: one is for the "preload", threaded portion, the other for the "runtime", read write portion that will be basically the one used by the program users to perform their tasks.
create 1 unit where to store the thread worker code
create 1 or more form(s) that will constitute your application.
The two data modules would look like this:
Preload module, to be managed by the worker thread.
Portion of the main database module. It includes several additional datasets that the preload module cannot preload. Those are typically "dynamic" datasets whose queries are directly affected by interaction with the users.
The main database module's components started as copy and paste of the preload module so it does not take twice as long to prepare both.
Both the preload and the main database modules come with a ConnectToDatabase and DisconnectFromDatabase procedures that perform all the steps required to have the system up and running.
Very important!
The preload module performs the "true" queries in a separate thread and fills in their related TClientDataSets. Its components have no events attached. I only use them as blind "static" data containers.
The main database module will just "attach" to the preload module components.
In example: whereas the preload module cdsProducts ClientDataSet performs a "true database query" with the
cdsProduct => dspProduct => qryProduct
chain, the main database module cdsProduct just takes the preload module's cdsProduct data without performing any query at all (otherwise what'd be the point, performing queries twice?).
You see how counter-intuitively enough, the main database module cdsProduct comes with a linked TDataSetProvider and query components as well. Why? Because I use them to write modified data back.
That is, we have three program phases:
Startup, where the preload data module performs the queries (in a thread) and that's it. No events managed, all read only.
Running-start phase, where the main database module (in the VCL thread) copies the data gathered in 1 into its ClientDataSets.
Running phase, where the users interact with the main database module's ClientDataSets. When they need to save data (and only then), the main database module's DataSetProviders and queries are engaged. They only write.
I could have skipped the whole ClientDataSet => Provider => Query chain for some of those ClientDataSets but most of them require some huge data processing, must update many joined tables by hand and so on, so I just used the full stack.
Code portion
Lets get to some more nitty-gritty details. I can't post the whole stuff since it's a commercial application so I'll only paste some significant snippets.
Threaded, preload data module
procedure TModDBPreload.ConnectToDatabase;
begin
dbcEShop.Connect;
SendStatusMessage('Loading languages archive');
qryLanguage.Open;
qryLanguage.First;
SearchOptions := [loCaseInsensitive];
ModApplicationCommon.ApplicationLocaleInfo.Lock;
...
try
...
// All the queries parameters needing a language id need to be assigned to the locked LocaleInfo object
qryGeoZone.Params.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
cdsGeoZones.Params.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
...
finally
ModApplicationCommon.ApplicationLocaleInfo.Unlock;
end;
SendStatusMessage('Loading countries archive');
cdsGeoZones.Open;
cdsGeoZones.First;
SendStatusMessage('Loading currencies archive');
qryCurrency.Open;
qryCurrency.First;
Sleep(100);
SendStatusMessage('Loading products archive');
cdsProduct.Open;
cdsProduct.First;
...
end;
The above snippet could use a lot of explanations. In particular:
SendStatusMessage('Loading languages archive');
is a thread sending an end user friendly update string to be shown on a status line. Of course the status line is managed by the main VCL thread. How to do it? I'll show it later.
qryLanguage.Open;
qryLanguage.First;
...
cdsGeoZones.Open;
cdsGeoZones.First;
Not all the datasets need to be managed for the whole application duration. Only those that need are managed by ClientDataSets.
The "First" calls happen because I don't know if the server back end will change. Some database drivers, DLLs, (expecially) ODBC connectors etc. etc. don't perform the actual heavy lifting during Open but at the first cursor operation.
Therefore I make sure it happens, even if the current driver does not strictly need it.
The Sleep(100) is there to let the users and the developers see the messages when opening small tables. May be removed once the software is final, of course.
The Lock, try / finally clauses etc. are there to remind you that we are in a thread and some resources are best accessed with some precautions. In this specific case we have other threads (irrelevant for this article, thus not covered) so we have to protect some data structures.
In particular, I have "borrowed" the basic Delphi thread safe list locking mechanism paradygm so the method names are also the same.
OmniThreadLibrary based preload module thread worker
Here is the most relevant / didactic code:
type
TDBPreloadWorker = class(TOmniWorker)
protected
ThreadModDatabase : TModDBPreload;
FStatusString : string;
public
constructor Create;
function Initialize : boolean; override;
procedure Cleanup; override;
procedure SendStatusMessage(anID : Word; aValue : string = ''); overload;
procedure SendStatusMessage(aValue : string); overload;
procedure DisconnectFromDatabase;
procedure OMSendMessage(var msg: TOmniMessage); message MSG_SEND_MESSAGE;
procedure OMDisconnectFromDatabase(var msg: TOmniMessage); message MSG_DISCONNECT_FROM_DATABASE;
procedure OMUpdateStateMachine(var msg: TOmniMessage); message MSG_UPDATE_STATE_MACHINE;
end;
...
constructor TDBPreloadWorker.Create;
begin
Inherited;
FStatusString := 'Connecting to server...';
ThreadModDatabase := Nil;
end;
function TDBPreloadWorker.Initialize : boolean;
begin
ThreadModDatabase := TModDBPreload.Create(Nil);
ModDBPreload := ThreadModDatabase;
ThreadModDatabase.DBPreloadWorker := Self;
DisconnectFromDatabase; // In case of leftover Active := true from designing the software
Result := true;
end;
procedure TDBPreloadWorker.Cleanup;
begin
DisconnectFromDatabase;
ThreadModDatabase.Free;
ThreadModDatabase := Nil;
end;
procedure TDBPreloadWorker.SendStatusMessage(anID : Word; aValue : string);
begin
FStatusString := aValue; // Stored in case the main application polls a status update
Task.Comm.Send(anID, aValue);
end;
procedure TDBPreloadWorker.SendStatusMessage(aValue : string);
begin
SendStatusMessage(MSG_GENERAL_RESPONSE, aValue);
end;
procedure TDBPreloadWorker.DisconnectFromDatabase;
begin
if Assigned(ThreadModDatabase) then
ThreadModDatabase.DisconnectFromDatabase;
end;
procedure TDBPreloadWorker.OMSendMessage(var msg: TOmniMessage);
begin
Task.Comm.Send(MSG_GENERAL_RESPONSE, FStatusString);
end;
procedure TDBPreloadWorker.OMDisconnectFromDatabase(var msg: TOmniMessage);
begin
...
DisconnectFromDatabase;
end;
procedure TDBPreloadWorker.OMSendMessage(var msg: TOmniMessage);
begin
Task.Comm.Send(MSG_GENERAL_RESPONSE, FStatusString);
end;
procedure TDBPreloadWorker.OMUpdateStateMachine(var msg: TOmniMessage);
begin
Task.Comm.Send(MSG_GENERAL_RESPONSE, FStatusString); // Needed to show the pre-loaded status
if Assigned(ThreadModDatabase) then
begin
try
ThreadModDatabase.ConnectToDatabase;
SendStatusMessage('Reading database tables...');
if not ThreadModDatabase.QueryExecute then
begin
raise Exception.Create('Consistency check: the database does not return the expected values');
end;
SendStatusMessage(MSG_SUCCESS, 'Tables have been succesfully read');
SendStatusMessage(MSG_TASK_COMPLETED);
except
On E : Exception do
begin
DisconnectFromDatabase;
SendStatusMessage(MSG_TASK_FAILURE, E.Message);
end;
end;
end;
end;
Some code deserves further explanations:
function TDBPreloadWorker.Initialize : boolean;
creates the preload data module. That is, everything is self contained in the thread's context and does not clash with others.
procedure TDBPreloadWorker.SendStatusMessage(anID : Word; aValue : string);
this is how to send a message (by the way, it's not limited to strings) to the main VCL thread by means of the OmniThreadLibrary.
procedure TDBPreloadWorker.OMUpdateStateMachine(var msg: TOmniMessage);
this is the main preload data module initialization management code. It performs handshaking with the VCL main thread and basically plays as one of the state machines I have implemented in the program.
For those wondering where all those constants come from: they are declared in a separate file included by all the threads related classes. They are simple, free to choose integers:
const
MSG_GENERAL_RESPONSE = 0;
MSG_SEND_MESSAGE = 1;
MSG_SHUTDOWN = 2;
MSG_SUCCESS = $20;
MSG_ABORT = $30;
MSG_RETRY = $31;
MSG_TASK_COMPLETED = $40;
MSG_FAILURE = $8020;
MSG_ABORTED = $8030;
MSG_TASK_FAILURE = $8040;
MSG_UPDATE_STATE_MACHINE = 9;
MSG_TIMER_1 = 10;
MSG_DISCONNECT_FROM_DATABASE = 99;
Main form side preload management code
The various threads are spawned at program start. A TOmniEventMonitor has its OnTaskMessage event pointing to:
procedure TFrmMain.monDBPreloadTaskMessage(const task: IOmniTaskControl;
const msg: TOmniMessage);
var
MessageString : string;
ComponentsNewState : boolean;
begin
MessageString := msg.MsgData.AsString;
if Length(MessageString) > 0 then
UpdateStatusBar(MessageString);
if task = FDBPreloadWorkerControl then
begin
if (msg.MsgID = MSG_TASK_COMPLETED) or (msg.MsgID = MSG_TASK_FAILURE) then
begin
ComponentsNewState := (msg.MsgID = MSG_TASK_COMPLETED);
// Unlike for the watchdog, the preload thread is not terminated
// The data is needed by the program till its end
// DBPreloadTerminate;
// Lets the main database queries be started
DBPreloadSuccess := (msg.MsgID = MSG_TASK_COMPLETED);
MainViewEnabled := ComponentsNewState;
if msg.MsgID = MSG_TASK_FAILURE then
begin
if MessageDlg('Unable to load the data tables from the database server', mtError, [mbRetry, mbAbort], 0) = mrAbort then
Close
else
// Reinitialize the preload thread.
...
end;
end;
end;
end;
This is the totally simple procedure that in the end gets called in order to update the main form's status bar:
procedure TFrmMain.UpdateStatusBar(Value : string);
begin
pnlStatusBar.SimpleText := Value;
pnlStatusBar.Update;
Application.ProcessMessages;
end;
Main database module management code
Last but not least, here is how to actually "attach" to the preload data module ClientDataSets. Call this code from the main form and the foundations of your application are basically done!
procedure TModDatabase.ConnectToDatabase;
procedure ConnectDataSet(CDS : TClientDataSet; PreloadDataSet : TClientDataSet; RuntimeDataSet : TZAbstractRODataset; SetLanguage : boolean = false);
begin
// Only required by datasets needing a locale_id parameter
if (SetLanguage) then
begin
CDS.Params.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
RuntimeDataSet.ParamByName('language_id').AsInteger := ModApplicationCommon.ApplicationLocaleInfo.LocaleIDForQueries;
end;
CDS.Data := PreloadDataSet.Data;
CDS.Active := true;
end;
begin
DisconnectFromDatabase;
dbcEShop.Connect;
UpdateStatusBar('Setting up products archive');
ConnectDataSet(cdsProduct, ModDBPreload.cdsProduct, qryProduct, true);
UpdateStatusBar('Setting up products options archive');
ConnectDataSet(cdsProductOption, ModDBPreload.cdsProductOption, qryProductOption);
UpdateStatusBar('Setting up options archive');
ConnectDataSet(cdsOption, ModDBPreload.cdsOption, qryOption);
UpdateStatusBar('Setting up options descriptions archive');
ConnectDataSet(cdsOptionDescription, ModDBPreload.cdsOptionDescription, qryOptionDescription, true);
...
I hope to have posted enough information to give out an idea about the whole process. Please feel free to ask any questions and sorry for the lexicon, English is my fourth language.
I am looking into a free solution to connect delphi with a mysql database but without using ODBC.Is there such a component ?
Thanks.
You can use either:
TmySQL latest version released on 2002.
mysql.pas which works with recent Delphi version (D3 through DXE2) / MySQL version 3.23, 4.0, 4.1, 5.0, 5.1.
i have been looking and using for years many tools, free and paid.
1st free is weak or difficult, at least u need too much code to do simple tasks which can be done in one or two functions in paid tools.
Paid tools i have used Devart MyDAC and microOLAP for MySQL which are the top rated tools in this area.
i used mydac for around 2 years, but lately i moved to MicroOLAP DAC for MySQL as a better alternative for many reasons
microlap mydac is much smaller, much easier to maintain and install and to use, mydac is much bigger details and many of these details and properties give unclear errors when used in some wrong way. since microolap is smaller, it is almost error free, and easier to use.
mydac has a unicode issue in TmyDump vcl component, which repeatly appear and fixed in next update and reappear in the next one, fixed in the next and so on. this bug creats a nonunicode backup file containing unicode data, which when restore with the fixed version will cause wrong unicode conversion and damage of data, MicroOLAP tool has no issue with that with its similar component and smaller amount of details.
i believe simplicity is much better than complications, easier, and much bug free. that is main reasons for me to convert to DAC for MySQL from MicroOLAP.
that is my simple experiement with this important basic subject for any serious database busniness developer.
i tried also the new FireDAC, i highly discourage to use it, too much complications, difficult unicode handling, difficult to deploy.
Have luck.
You can use dbExpress. The only thing you will need is libmysql.dll from 5.1.X server.
I have been using MyDac since years, which is one of best DAC components for Delphi.
AFAIK it's the only native component that offer Direct Connection to MySql (No ODBC, No OLEDB, No libmysql.dll).
This is what I use in Delphi XE4 (works in previous versions too). It creates components during runtime. Note: if you want to create databases, the default MySQL database 'mysql' needs to be used. Make sure you check if you have access to it, put try..except..end; in your code. And yes, it requires having dbxmys.dll and libmysql.dll in the same folder as your *.exe. This video might give you some hints http://www.youtube.com/watch?v=6mRGAB4LsEE
unit MainUnit;
interface
uses
System.SysUtils, System.Types, System.UITypes, System.Rtti, System.Classes,
System.Variants, FMX.Types, FMX.Controls, FMX.Forms,
FMX.StdCtrls, Data.DBXMySQL, FMX.Edit, Data.DB, Data.SqlExpr, FMX.Dialogs, Windows,
Data.FMTBcd, FMX.Layouts, FMX.Memo, FMX.ListBox, FMX.ListView.Types,
FMX.ListView;
type
TForm3 = class(TForm)
Button1: TButton;
Label1: TLabel;
Edit1: TEdit;
Memo1: TMemo;
ListBox1: TListBox;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
MySQLConnection: TSQLConnection;
MySQLQuery: TSQLQuery;
Function ConnectToMySQLDatabase(szHostName, szUserName, szPassword, szDatabaseName: String): boolean;
end;
var
Form3: TForm3;
implementation
{$R *.fmx}
procedure TForm3.Button1Click(Sender: TObject);
begin
if ConnectToMySQLDatabase('localhost', 'root', 'passw_ord', 'table_name') = False then
Caption := 'Not Connected'
else
begin
Caption := 'Connected';
try
MySQLQuery.SQL.Clear;
{MySQLQuery.SQL.Add('insert into table_name(vardas_pavarde, asmens_kodas, kodas, pazym_nr, registravimo_data, '+
'data_nuo_kada_taikomas, isregistravimo_data, negalioja_nuo, paskelbimas_negaliojanciu, priezastis, pastabos) '+
'values ("Edijs Test", "3001000", "38", "PazPK122", "2013.05.03", "2013.06.01", NULL, NULL, NULL, "Tuščia", '+
'"ąčęėįšįųūž");');}
MySQLQuery.SQL.Add('select * from table_name where vardas_pavarde="edIJS tEst";');
MySQLQuery.Open;
Memo1.Lines.Add(VarToSTr(MySQLQuery['vardas_pavarde']));
Memo1.Lines.Add(VarToSTr(MySQLQuery['asmens_kodas']));
Memo1.Lines.Add(VarToSTr(MySQLQuery['pastabos']));
MySQLQuery.Close;
except
on E: Exception do
MessageBox(0, PWideChar(E.Message), 'Error', MB_ICONERROR);
end;
end;
end;
Function TForm3.ConnectToMySQLDatabase(szHostName, szUserName, szPassword, szDatabaseName: String): boolean;
begin
MySQLConnection := FindComponent('MySQLConnection') as TSQLConnection;
if not Assigned(MySQLConnection) then
MySQLConnection := TSQLConnection.Create(Self);
MySQLConnection.DriverName := 'MySQL';
MySQLConnection.GetDriverFunc := 'getSQLDriverMYSQL';
MySQLConnection.LibraryName := 'dbxmys.dll';
MySQLConnection.VendorLib := 'LIBMYSQL.dll';
MySQLConnection.Params.Values['HostName'] := szHostName;
MySQLConnection.Params.Values['Database'] := szDatabaseName;
MySQLConnection.Params.Values['User_Name'] := szUserName;
MySQLConnection.Params.Values['Password'] := szPassword;
MySQLConnection.Params.Values['ServerCharSet'] := 'utf8';
MySQLConnection.LoginPrompt := False;
try
MySQLConnection.Connected := True;
MySQLQuery := FindComponent('MySQLQuery') as TSQLQuery;
if not Assigned(MySQLQuery) then
MySQLQuery := TSQLQuery.Create(Self);
MySQLQuery.SQLConnection := MySQLConnection;
Result := True;
except
on E: Exception do
begina
MessageBox(0, PWideChar(E.Message), 'Error', MB_ICONERROR);
Result := False;
end;
end;
end;
end.
Use DB Express with MySQL 5.x in Delphi 7
See this link
http://www.justsoftwaresolutions.co.uk/delphi/dbexpress_and_mysql_5.html