 Hello, my name is Tama Munt and I would like to present something about databases, but let me introduce myself first. I started to work on libraries around some years ago, with a really clever database management systems driver for libraries. After that, I started to work with Kolomotor, with lots of things which are not related to databases, or databases of the group. But after that, I worked, and it was in the winter, I worked on the database foundation part, which I want to talk about. First, let me ask a question. Do you know what your database is? I think I've already used it. Hands-on group. Yes, thanks. That's half of the group, which is positive, because the other half just made me just lazy to put the hands-on. Thank you very much. Then I would like to talk about what are the main topics in my presentation. I would like to talk about the continuation of them. I will go into detail of the development process. Then I would like to suggest further development, opportunities after that, if I have time, that I will make a demo of the migration thing. What is it all about? We have this database, which is the run-hand of several database management systems. We had the opportunity to store our databases embedded into the ODB farm, which in this case, we can use SQLDB or Fireworks as a backup. There was this idea that not SQLDB should be default database management systems, but Fireworks, which is good for several reasons. For example, we want to get rid of the Java code in the Office Store, because it's a big dependency, and we don't want to shift that into the graphics art. We don't want to use it to configure such things. Another, more complicated, is the developers, because SQLDB is a Java case, and because of that, we need to use Java from C++, that means through Java native with API, and because of that, it's hard to move back. For example, if you press backtricks from GDB, you can't see the actual SQLDB code, just the mapping to the Java code. Another thing, I think this is for the priority, but it's just my opinion. It must be my own performance, and that means that C++ native code should be faster than Java code. And I found the question which is interesting. We use SQL and the answer would be for that, in my opinion, that SQLite is a feature of each SQL Fireworks, and my opinion from SQLDB to SQLite would mean that we lose some features. Okay, so now we come to the tender. GDF has probably done a lot of this migration thing. When we want to migrate to Fireworks, we have to make a bit able to look at points on database files even if there are no Java points that we use, which we use to promote this database. But before that, the Fireworks driver will be less likely to lose some features or that it cannot be... If you can't notice the migration, that's not just possible. Before that, I implanted that we finish the migration of some types in the Fireworks driver, which we did for the migration, and there was also another part which was about popping integer values from Firebase. It was quite interesting that I wouldn't have to go into detail there. Before I present my solution for this migration thing, I would like to introduce the form of SQL Database. Can we look at the ODB files and see if it's actually... You can find it in the folder on the database, and there are two files. One is the text file on script, and there is a data file. The script file contains the Schickman definition as in a form of a student, that means a great table, my table, and so on. And some other information, for example, it shows us that it should be in the data file. That means, for example, if I have a table on my table, I got a form from the script file, and the data from my table is located at this position in the data file. If you can see that, but it's not that important, that's the script file. The script file contains SQL, and I want it to highlight one row, which you see about it, probably, as I told you. Whatever, so this is the position in the binary file where you can find the data of the table. We actually have to look into all this in the Schickman definition, where we migrate the data, and we have to write it among the other database. Again, the other part of the course is to be entirely binary file. This is the figure of AVL3, that's a balanced binary picture, and I got to know that the SQL database stores its data in that format. It was about logging the source code, it wasn't much documented, but the source code was really understandable. I wouldn't have to go into much into how it works, but when we had the Schickman information from the script file, we could look at the binary data, and the migration tool, which is interesting from here, might be that this browser is the main class, the only class in Schickman that's outside of this migration tool, and you can call this SQL database to make the migration process, and it needs two fields, the storage which, which tells us with which we can access the internal files, so the script file and the data, and this connection is part of the SDBC driver, which is the abstraction, we learned the base connection, and we need that in order to execute the commands which we had found the script file, and we can set the data through this connection. And there are two main parts of the migration tool, the Schickman constant, which is under that, it's a great response because of all the read again, and then the definition, and this, this is a response, a part of the response in both words, reading the binary file. Okay, now I would like to highlight the interesting challenges from that. The first one, a lot of, reading of the watch, if not that interesting, but it's an example, if I look into the pattern structure, so the data file, let's say that one's in different, and say it's x down to the files of the diagram, so it's internal structure, and I can see the four bytes, which are the size of the watch, and that's the thing that's, I think, complicated. I had some trouble with the numeric, dancing one, and the types, because it was representative in the binary files, the big Java ones, which is an integer format. It's something like an integer, but it can be, if it's longer, longer than an integer, and I had to convert it to string, because the representation of the string, because as it is, it uses that for communicating the decimal numbers, and I, first, I tried to make a binary algorithm, and that was, that was, that was, so I was happy with that, but then I would make an internal and then I would convert it into an algorithm, and work that, and it works just fine. I thought that stuff, that I had to do, was the migration of the time, and so, that's interesting, because there are three different representation, the ethnography, the history, the history, as the time from 1970, as the history starts from zero, and fireworks start the test time from nine, from 100, 100, 1,000, 100. So, I had to convert each one of these tasks, I made some tests, I think that's that interesting, and yeah, another program, with the time, the migration of time, in Turkey, it's the values, as an operation system, time zone, dependent format, that means that, if you run legal office base, not the user way, you update your date in time, before you issue the comment, for example, the time zone, then you realize that the date is changed, and I think most of the discrepancy would surprise about that fact, although fireworks knows time zone westerns, there is a lot of people who may come in version, but yet it's not happening, and it's possible to create a pop-up window, which, as the user, demands, is that, as the user, it's not happening.