I have a infoPower Grid that is bound to the TQuery Component with following sql
SELECT membership_number, message_id, msgText,target, date_time_creation,
date_time_display
FROM MessageMembership
WHERE membership_number = :membershipnumber
ORDER BY date_time_display desc
qalso I have bind it to the dbnavigator as well as DataSource which is binded with The InfoPOwer Grid. Now insert and delete and update buttons are enable but insert button dont let me type the new values also update button dnt let me type the updated value. But delete is working as expected. What can be possible issue or step I am missing?
The code for executing TQuery is :
MessageMembershipSelectQuery.ParamByName('membershipnumber').AsString :=
custQuery.FieldByName('cust_code').AsString;
MessageMembershipSelectQuery.Open;
Please help me.
TQuery is a BDE dataset. It won´t let you edit it´s contents unless the RequestLive property is set to True and you have a TUpdateSQL component bound to it, by the UpdateObject property. Those two properties work together to enable the batch mode of BDE, which is named cached updates.
However, I strongly advise you to not invest in BDE, not even to learn how to program in Delphi. Much better is to start studing the way of TClientDataset. It´s a much more functional dataset that will give you more control over all parts of your application, from selecting to updating data.
The nice thing about TClientDataset is that you will isolate the SQL dependecy of your application away from the main domain logic, which will be written all around TClientDataset. That logic will be data-dependent, not SQL-dependent.
Think about it: now you have an application that works with MySQL. Then, suddenly, you have to port it to work with Oracle. If you isolate your SQL dependency away from the main code, this refactoring will be much faster and safer.
Remember: BDE is dead.
Related
I'm trying to load about 500k+ data linked to an Oracle DB on my TcxGrid, I want to make the process faster using the GridView "GridMode" property, but I need to do that using a TSQLQuery (DBExpress Component) and it just doesn't work, Gridmode seems inoperable (doesn't load data faster on the Grid, doesn't load custom quantity of records using the "BufferCount" property, etc.)
Here I created a TSQLQuery component and used a query script for my 500k table (for performance purposes I just got 500 values but I need to load 500k+):
TSQLQuery
When I link the TSQLDataSet to the Grid and activate the TSQLQuery it shows all the records from the query, even if the GridMode is TRUE and the GridModeBufferCount is 5
GridWithTSQLQuery
On the other hand, when I use a TQuery, the GridMode just works properly, in this case I had to open SQL Explorer, make the connection and assign that connection to the TQuery DataBase property:
SQLExplorer
Here I show my TQuery with the values mentioned before:
TQuery
And when I activate my TQuery.. voilá:
GridWithTQuery
What I'm doing wrong? or do I need to do more things on my TSQLQuery besides linking it to my dataset and then linking the dataset to the grid?
It's impossible that a very old Tquery can do this and not a newer dbExpress component
Thank you so much guys
I have a mainForm with a DBGrid and I have a second form with a CheckListBox that shows all of the DBGrid columns for the user to choose. I need to reference in Form2 the DBGrid that I have in MainForm.
I would like this second form to handle all of the procedures connected to the dbdgrid columns , so that I can reuse it easily.
That was the idea, but I dod'nt find the way to pass the DBGrid reference.
Is it possible ?
Answering the question you asked, on your Form2, define a property
TForm2
[...]
private
FGrid : TDBGrid
public
property Grid : TDBGrid read FGrid write FGrid;
Then, after you've created an instance of TForm2, just do
Form2.Grid := MainForm.DBGrid1;
Then, on Form2, you can do anything valid you like to change Grid and the changes will be made to MainForm.DBGrid1.
Is it possible?
The question should rather be Is there a better way to achieve what I want?
Would it be maintainable if Form2 worked basically with a control from a different form? What if other forms would also need to hold references to components on other forms?
How hard would it be in a year to find a bug if controls are used over different forms?
Would such a solution match to the SOLID principles?
Answering these questions should help you to look for a different approach.
You should consider to separate UI and business logic. A TDBGrid seems to be a convenient way to get data from a database into your application but it violates the Single Responsibility Principle since it loads and displays data at the same time. Don't use it as a basic data provider inside your application. Perform the SQL queries from a deeper UI independant layer of your software. Store the results in containers and display them in all the ways you want in your different forms.
When I use a TClientDataSet which is connected to a TxxxQuery component, I can add TFields to both components at design time. I recognized, when I don't specify the TFields in the TxxxQuery component, they are retrieved when the query is executed at runtime.
My questions is: Is there a performance difference when I add the TFields at design time to the TxxxQuery component?
When you add the fields at design time you get the strongly typed QueryName_FieldName fields you can use directly from code, skipping the name-based QueryName["FieldName"] lookup required if you don't have them.
From a performance stand-point the difference is most likely insignificant; From a language perspective having the fields added at design time provides better type safety, but only if you access the fields from code, and only if you use the QueryName_FieldName.Value syntax, not the named-based QueryName["FieldName"] syntax. If you use data-bound controls there's no difference.
I personally only add fields to TClientDataSet at design time when I need to use the client dataset without binding it to an other data source (ie: use it as a temporary table for reporting).
I'm building an application using IW 8 and Delphi 7. Application is 3-tier.
1) on the app's datamodule I have several TClientDatasets and TDataSources associated(set on master-detail relationship)
2) on an IW form I have several TIWDBLookupComboBoxes with datasets pointed to datamodule datasources.
The problem I'm facing: when I select a value from one of the TIWDBLookupComboBoxes, the datasets don't react(I'm changing the index of the master dataset, so the detail dataset should also change). So I saved the clientdatasets to xml files and imported the data into a win32 application, set all the master details in the same manner, and voila - everything is ok.
So my question is: it seems that TIWDBLookupComboBoxes don't move the internal cursor of the datasets? If so, on the OnChange event of the TIWDBLookupComboBoxes, if I set the recno to what I want I'll have problems with forms rendering?
how can I solve this?
I resolved this by using simple IWComboBox components, and on the OnChange event setting up the RecNo property to the combobox's index+1(itemindex is 0 based). Other solution is to make a filter on the dataset with the combobox's value.
alt text http://img29.imageshack.us/img29/825/simplemodel.jpg
How you can see above, it's a kind of subclass a table in a RDBMS (in this case, my favorite: MySQL) so I handle it with Visual Subclassing a base form for tb_order_base with validating field data, etc.
This way, I'm free of repeating code and some other bothering problems, well, it seems a true OO aproach. But ...
Now I got a Big problem with subclassed form i.e. tb_order_service with a master/detail approach, when I post the tb_order_base dataset, instead of Delphi first post it and get the PK ID from RDBMS and then post the TB_ORDER_PRODUCT with id filled, it does the opposed, posting the detail tb_order_product dataset first then master tb_order_base, so I get a big foreing key constraint error.
Does anyone has any idea to how to by-pass this amazing problem?
I have asked it before, but with few details in The Master/Detail Behavior
One thing I have done in such a condition was to break away from doing DBMS direct calls, and to instead use a memory dataset (or client dataset) for the form. When the user presses the save button, I would validate my edits and return any errors. If no errors then I would begin a database transaction, commit the master record (and then read the master record key back if its an insert), then run thru each table commiting the child records, followed by a commit of the transaction (or rollback if there were any problems saving child data).
I also stay away from using data-aware components. They work great for simple utility type programs, but when you start creating a complex system using them you will find little gotchas along the way that are easily solved by using a standard edit and a function to push/pull data to/from the database. The only exception I generally make would be for grids, but I only use the grid for selection...the actual editing is done using non data-aware components.