Stano

I had no idea it was interactive. Thank you. It's OK now.

Asi mám špeciálnu stránku Nikde ju nevidím.

I can't find where I can download my license file. What is its name? Thanks!

I ran it 10 times. No result.

Now I've tried it. The result is the same. Nothing.

I foresee the next stage of improvement. To make the descriptive text (in Memo) formatted - RTF.

While this is a simple case and serves to teach, I do suggest one change there. Let it be as it should be. Create a TDataModule and put a FireDAC on it: WaitCursor Connection Transaction The TFDTable-s in the whole project will connect to the DB using MyDataModule.MyConnection. The appropriate code from the form will also be moved to the TDataModule. I didn't want to write this by the shovelful. Since you didn't get it, here it is exactly: if TableDino.Locate('record', iSelect, []) then As you can see, I'm not searching by text, but by number. This is always faster and more certain.

Try if TableDino.Locate(name, iSelect, []) then ShowMessage('Succes') ele ShovMessage('Issue'); Name := 'RECORD'; My previously attached sample shows this nicely.

This is not a criticism. These are comments (advice) based on experience, read recommendations and comments from the experienced. I've had my fill of those comments. Some have been quite harsh. Maximizing the window: I want to have a running application available - especially during development. See image. Can't you do a double-click on the image? I can't switch it to another mode - size can't move it you can't even collapse it be aware that with my monitor resolution of 3440 x 1440 it's driving me to despair Table "dino": Capitalization is based on practice and some convention, convention. Note that all published SQL text and metadata is capitalized some DBs require it hardcoded it's good to stick to conventions Record lookup: "randomly" I meant they are not alphabetical since I read the recent article, there has been a change in the breakdown of eras. I don't know when. And you may already have order problems *) those hints are meant in general. You're not supposed to apply them to one case *) such things are dealt with e.g. the primary key must always be insert the next column with the order. Depending on the situation it may be: close behind with spaces To repeat: the physical order of records in tables is not guaranteed. Query with frequent ORDER BY is always used for this!

My 200 cents You have to make the app the way the whole world should use it! Throw out that maximized window. We already "require" it for two. You've got a picture of why at the end. It's for illustration purposes only. Every app has to remember: the position of each window/form the size of the form the content of the form Now this is premature, but you get the point. Table "dino": everything should be capitalized name DINOS field "record": is a reserved word it must be a Primary Key (PK). Values for PK are generated automatically. They have nothing to do with the order of the record. During DB maintenance, the order of records in the table may change Record lookup: Users are used to searching alphabetically you have entries written "randomly" if the table (not only dino) will have a lot of records: ComboBox will have large responses. I used it as one of the options. Note the record lookup you have to have a search there by typing the first letters. I don't know if you meet that I solve it with VirtualStringTree (VST) at the same time I use it for basic record display. Instead of DBGrid. It has the following advantages: you have full control over everything - very important it is really fast you can sort the records by the selected column. Ascending or descending has a built-in node search by column you can filter the records Disadvantage I had to make my own DBManager for it. This can be worked around Task for the future: It belongs to make there the possibility to edit records: insert, update, delete... Sorry, Google translator.

Table names are always plural!

But in my PC there is not exists this path. That's why I don't understand it. That would be because it's created using the CE version and I haven't changed anything. I would have to destroy the automatically created files. I don't know in which one the information in question is located.

My humble remarks // I would kill for this. You don't know what I'm doing and what's on my screen. WindowState := wsMaximized; //Maximize the window Set CustomTitleBar.Enabled = True is not a good idea. procedure TfrmDino.FormCreate(Sender: TObject); //Form creation begin lbxData.Visible := False; // That was missing here Rename the RECORD field to IDDINO or DINOID or PKDINO or DINOPK I modified the record search using ComboBox. Remark: For my own use I changed the DB in conPLife. Because the suggested dynamic path setting gives me nonsense. I'm not that familiar with it. D:\Delphi_11_Community\MyProjects\Dinobase\dino.db My path d:\Dokumenty\Z internetu\PrehistoricLife\dino.db Dinobase_u.zip

I tried the link. Just a blip and nothing more. Put it here as an attachment.

Put a picture of the form here at the time of design. Let us have some idea of what you are doing and probably how you are doing it. That way we're just guessing from the coffee.

Yes. But you are using a modified DBNavigator. See also the reply from JonRobertson.

Hm, I've opined that you should get rid of your DBNavigator altogether. You're supposed to make do with a standard one. Without the added buttons! Everything is linked to the record search in SearchBox. You chose the wrong methodology.

In that case, I recommend you to go to "help" and always check all the properties and methods of what you are interested in. You want to use. In this case, it's DataSet. After that, T(FD)Table and T(FD)Query are also included. They are its descendants. They inherit from it. This is a very best and recommended practice!

I personally wouldn't add buttons to a standard component. You need to use what is there. DBNavigator takes care of the button control automatically. You're supposed to use the DataSet.Locate() function in SearchBox.OnChange(?). Or another appropriate event - we don't know what you do where. I don't use SearchBox. I prefer ComboBox. That way you won't have to worry about anything. No additional buttons. Don't forget that you'll be using DBNavigator in multiple places. So don't break it.

Nobody knows what you're doing there. If you type a name in the search box, you also have to make sure that the record is set up correctly in the DataSet. Preferably using MyDataSet.Locate(PKeyName, PKeyValue, [loCaseInsensitive]); I'm assuming there's a bug there.

No, no. Things happen in the back that you ask him to do. But you have to make sure you update the data you see. That's what I was warning you about. You'd see that when using DB components. At least for learning purposes, put a DBGrid in there. You'll immediately see what's going on there.

GROUP is a reserved word. See "GROUP BY". That's why it doesn't work. Reserved words cannot be used in MetaData. You're supposed to have TDBEdit instead of TEdit. It seems to me that someone has written that to you here as well. Unless you didn't want to use DB components. I had such a period. I just had everything handled centrally using a class. If you're not going to have it that way, you'll have to take care of: retrieving data from the DB updating data e.g. changing a record storing the data in the DB It's a lot of extra unnecessary work. Plus a high probability of errors! One more addition. Use only capital letters of the English alphabet everywhere in the DB (MetaData). In the Delphi code, write the whole expression for Query.Sql.Text in uppercase as well. The reason for this is that some DBs require it. That's why I have set this as a default for myself. What if the DB changes? That's how I've seen it with all the pros as well.

In this case, put all affected components on the panel. Then set MyPanel.Enabled := False; Remark: For bulk setting of component properties on forms, I recommend to create a recursive function and deal with it there. be direct or create a list of components and work with it

FireDAC offers very many possibilities. I only know UniDAC for FB. The latter is very far beyond its capabilities. It needs to be well considered. It is a shame to lose them.

Inporting data from one DB to another has nothing to do with Delphi. Firebird (FB) runs on all Windows and many other platforms. I, as a layman, would not go into Interbase Lite. FB is always free for all states. That will not change in the future. I don't use any other DB. Importing data can be done in many ways. It depends on what you have available. One option is offered by Delphi itself. Something like BatchMove. It has been discussed here recently. You'll have to look it up. Given knowledge, I don't recommend it at the moment. I've done importing data from DBF as follows: I got the data in *.csv format I opened them in Excel and made the necessary adjustments field names corrections to the data. E.g. 1500 to 1500, dates, etc. Using DB Workbench, a commercial product, I performed the import