Delphi with Intraweb 8 - TIWDBLookupComboBox - master detail - delphi

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.

Related

How to refence a DBGrid from another form

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.

Has disabling TDataset.ObjectView side-effects?

Today I stumbled over the adt field types in Delphi Datasets. We use custom client datasets to bind objects to datasets in our views. With that dataset and our custom derivation of TDbGrid and enabled FastMM4 full debug mode we get an access violation with the following stack trace:
System.Generics.Collections.TListHelper.DoIndexOfFwd4((kein Wert))
System.Classes.TComponent.FreeNotification($7F961CE0)
Vcl.DBGrids.TColumn.SetField($7F971700)
Vcl.DBGrids.TColumn.GetField
Vcl.DBGrids.TCustomDBGrid.Notification($7F971220,???)
System.Classes.TComponent.RemoveFreeNotifications
System.Classes.TComponent.Destroy
Data.DB.TField.Destroy
System.TObject.Free
Data.DB.TFields.ClearBase(True)
Data.DB.TFields.ClearAutomatic`
Data.DB.TDataSet.DestroyFields
Datasnap.DBClient.TCustomClientDataSet.InternalClose
Data.DB.TDataSet.CloseCursor
Datasnap.DBClient.TCustomClientDataSet.CloseCursor
Data.DB.TDataSet.SetActive(???)
After some debugging fun, i found out that the internal FieldList of the Dataset contains a already destroyed field. After doing some more reasearch, I found out that disabling property
DataSet.ObjectView
disables the internal FieldList and the access violation goes away.
As we don't use ADT field types, I suspect disabling it does no harm, but one never knows.
Background
I've had already a lot of problems with TDataSet and TDbGrid, starting with the inherent problems of the flickering scollbar in the grid and ending in corrupt BCD-Parameters for oracle databases. We updated from XE3 to DX10, the access violation did not occur before.
I can not post the code of our custom dataset / custom grid
we are freeing the dataset before the grid

Delphi Infopower Grid with dbNavigator

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.

How to create a report using fast Reports with out connecting directly to a database

I have been asked by my company to update the reporting functionality of a paticular application written in delphi and using Quick reports to use FastReports instead.
The current implementation pulls all the data out of the database, does a lot of work to organise and calculate the required data for the reports and stores all this in several different objects. The Quick Report OnNeedData events are then used to fill out the bands until there is no more data (signified by setting MoreData = false)
The problem I'm having is Fast Reports seems to need a band to be connected to an actual data source, which I don't have. Also fastReports doesn't seem to have an event similar to OnNeedData.
Is there anyway to fill out the values of a data band in code and have it print again until all data is printed without connecting the band to a dataset?
I appologise for the vagueness of this question, I am very new to reporting software and any suggestions of where to go and what to look at would be greatly appreciated.
Fast reports use a intermediary object descending from _TFrxDataSet to connect the report engine which the data it prints.
To connect a report to a data source managed by the program itself, you use a TfrxUserDataSet component, which let's you see a data set inside the report, but you manually specify the column names in the Fields (TStrings) property and manage and supply values programatically writing event handlers for the following events:
OnCheckEOF is functionally equivalent to the OnNeedData, if there's no more to print, you set the EOF var parameter to true
OnFirst you do whatever you have to do to start walking for the data.
OnGetValue and OnNewGetValue you provide values for each of the different columns of the current row
OnNext, OnPrior you move your current row one next or one prior position.
As you see, the row/column concept (a DataSet) is used to provide the data to the report, but you can pull your data from any structure you use to store the result of your calculations (lists, arrays, or any other object/structure/file etc.)
Inside the report, you link the band to this logical DataSet and you use standard components to print the column values of this DataSet.
If you already have the data in a DataSet, for example a in-memory DataSet after your calculations, better use a TfrxDBDataset to directly bind your report to that source of data.
you can use TfrxUserDataSet.There is a demo named 'printstringlist' under folder 'demos'.
In our project we have implemented our own class inherited from TfrxCustomQuery. This new query class simply redirects its SQL statements to our application' internal query engine. We registered this new class in FastReport palette (used frxDsgnIntf.frxObjects.RegisterObject* for FR version 3 and 4) and now it is used in all our report templates instead of TfrxADOQuery or other built-in dataset classes.
Here is another alternative:
I've been using FastReport for years. I sometimes run into a similar situation. For offline tabular reports I use an in-memory dataset. I purchased DevExpress long time ago and so I have TdxMemData. But even without it, you should be happy using the TClientDataset component.
Besides that, the TfrxUserDataset is an alternative which I use when showing lists of objects.
There is a possibility to do it like this, it is slow though ,
Code:-
var
FRX: TfrxReport;
procedure NewPage;
begin
MyPage := TfrxReportPage.Create(FRX);
MyPage.CreateUniqueName;
MyPage.PaperSize := DMPAPER_A4;
end;
procedure ...(AText: string);
var
frMemo : TfrxMemoView;
begin
frMemo := TfrxMemoView.Create(MyPage);
frMemo.CreateUniqueName;
frMemo.Text := AText;
end;
Regards
Herman

Using a ClientDataSet in Delphi, are you able to display both Data & Delta records in a DBGrid?

I am making a app in Delphi 6 + MySQL database using standard data-aware components and dbExpress. The app allows a users to view records in a grid and edit data (insert and/or delete records) client side. These data edits are then only written to database on clicking the submit button. All of this works fine and has the following setup:
Controls:
1. DBGrid1 linked to a DataSource1 to display data visually.
2. DataSource1 is linked to ClientDataSet1 to offer data for DBGrid to display.
3. ClientDataSet1 is linked to DataSetProvider1 to provide client-side data for editing.
4. DataSetProvider1 is linked SQLDataSet1 which selects records from a single DB table.
5. SQLDataSet1 is linked to SQLConnection to provide connection to MySQL database.
Actions:
1. User inserts a record: I use ClientDataSet1.InsertRecord;
2. User deletes a record: I use ClientDataSet.Delete;
3. User submits data: I use ClientDataSet1.ApplyUpdates(-1);
This all works great in terms of handling data & posting data (with the inclusions of a small hack on DataSetProvider1BeforeUpdateRecord to delete records).
NOW FOR MY PROBLEM:
When the user first loads the form, the DBGrid1 displays all original records, removes all deleted records. But when the user inserts a new record in ClientDataSet1, a blank record is displayed in DBGrid1. The actual data is not lost or set as NULLS as when you ClientDataSet1.ApplyUpdates, this record is correctly written to the DB.
I know TClientDataSet has a data property for original data and a Delta property for edited data. Can these two properties with data by displayed in a single DBGrid at one time & still allowing the user to edit the data?
I have looked at 30+ resources and demo apps & all avoid this issue. Can this be done?
Ok...this question has been viewed a fair amount without much feedback. I did some research by downloading many tutorials, demo apps & read multiple articles/help info discussing the use of these controls.
The net result:
These controls are a bit buggy in general.
In specific reference to my question, it is safe to say the controls cannot do what I describe as a standard.
This is based on the 30+ demo apps, articles and tutorials I reviewed that either don't describe displaying both the original data with Delta data in a single data grid. Sure you could hack this outcome (which is what I did) using a Listbox or StringGrid, but that also indicates the control cannot or not usable at providing this functionality (on the slim chance it might).
This functionality is an obvious oversight in my opinion as a user wants to see the potential outcome of their actions, conveniently in a single data grid AND a developer wants to provide that in a simple & pain free way i.e. using a datagrid to display data!
Question Answered [if you can prove differently with a demo app that I want to review, I will remove this].
If you created a demo app and couldn't get it to work, up vote my answer. Thanks
The TDBGrid control provided with Delphi does not have the built-in functionality to display both the old and new values for fields. You are welcome, of course, to inherit from the Grid or create your own and add the functionality, or buy a third party component that accomplishes what you want. You are not limited to the standard controls, though they do provide the most commonly required functions.
You can also accomplish what you want by using calculated fields. For example, if you have a String field Name, add a new calculated String field to the dataset called OldName, with the same length as Name.
Then in your OnCalcFields event for the dataset, simply enter code like the following:
if DataSet.State = dsEdit then
begin
DataSet.FieldByName('OldName').Value := DataSet.FieldByName('Name').OldValue;
end
else
begin
DataSet.FieldByName('OldName').Value := Null;
end;
TClientDataset will handle itself the correct record status. Changes are logged, but unless you ask it explicity to show some other status (see StatusFilter property), it will show the actual state of a record.
It is possible InsertRecord bypasses some notification mechanism, so the field display is not updated. What if you perform simpy an Insert and the set field values?

Resources