Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 9 of 9 total |
migration problem |
Sun, Apr 29 2007 8:20 AM | Permanent Link |
"Iztok Lajovic" | Tim,
I started to work on migration of my first application to EDB. I wanted to migrate programmatically and I used the code published in migration help. Process stops with AV: with Migrator do begin SourceDatabase := SourceDatabase; SourceDatabase.Session.GetTableNames('Source', SourceTables); <<<<< AV Then I included the code of edbmigrate.pas into my code and found that the procedure TEDBMigrator.SetSourceTables(Value: TStrings) has no compiler marks i.e. is not reachable or not called within the code. It seems to me that this is the point of AV. If I want to migrate with EDBManager I get the message '4.00' is not valid floating point value. The last build I can download is Version 1.02 Build 1 Regards Iztok Lajovic |
Mon, Apr 30 2007 3:42 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Iztok,
<< I started to work on migration of my first application to EDB. I wanted to migrate programmatically and I used the code published in migration help. Process stops with AV: with Migrator do begin SourceDatabase := SourceDatabase; SourceDatabase.Session.GetTableNames('Source', SourceTables); <<<<< AV Then I included the code of edbmigrate.pas into my code and found that the procedure TEDBMigrator.SetSourceTables(Value: TStrings) has no compiler marks i.e. is not reachable or not called within the code. It seems to me that this is the point of AV. >> Sorry about that - it's an error in the source code published in the example. You need to use: Migrator.SourceDatabase:=SourceDatabase; Migrator.DestDatabase:=DestDatabase; instead right before the: with Migrator do line of code. It should look like this instead: Migrator.SourceDatabase:=SourceDatabase; Migrator.DestDatabase:=DestDatabase; with Migrator do begin SourceDatabase.Session.GetTableNames('Source',SourceTables); OnStatusMessage:=StatusMessage; OnProgress:=Progress; Execute; end; The way it is currently written, the with block causes a nil to be assigned to both the SourceDatabase and DestDatabase properties. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Apr 30 2007 4:16 PM | Permanent Link |
"Iztok Lajovic" | Tim,
thank you. Now it works. I have another question. To open DBISAM table I made a shortcut to open files with .DAT extension with DBSys. When I double clicked to a file, DBSys opens it at once. If I make shortcut with files with .EDBTlb extension, EDBMgr starts after double click, but selected table cannot be opened because EDBMgr does not find proper database. Obviously this information is stored in catalog file which location is not known when I double click on table in selected directory. There is a much longer way to open files with EDBMgr than it is with DBSys. Is there any possibility to shorten necessary steps to open files? Regards Iztok Lajovic |
Mon, Apr 30 2007 5:04 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Iztok,
<< I have another question. To open DBISAM table I made a shortcut to open files with .DAT extension with DBSys. When I double clicked to a file, DBSys opens it at once. If I make shortcut with files with .EDBTlb extension, EDBMgr starts after double click, but selected table cannot be opened because EDBMgr does not find proper database. Obviously this information is stored in catalog file which location is not known when I double click on table in selected directory. There is a much longer way to open files with EDBMgr than it is with DBSys. Is there any possibility to shorten necessary steps to open files? >> ElevateDB isn't file-based like DBISAM, so it really isn't possible to open up tables with a double-click like it was in DBISAM. All of the information regarding which tables exist, etc. is stored in the database catalog. -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Apr 30 2007 7:44 PM | Permanent Link |
"Ian Branch" | Tim Young [Elevate Software] wrote:
> > ElevateDB isn't file-based like DBISAM, so it really isn't possible to open > up tables with a double-click like it was in DBISAM. All of the information > regarding which tables exist, etc. is stored in the database catalog. Now there's an unforseen productivity blocker. I regularly open my data files that way when testing. Perhaps an '.ini' file or similar in the relevant data directory or somewhere could point the relevant catalog drive/directory?? EDBMgr could test for the presence of the '.ini' file and use it if there. Just a thought. Regards, Ian -- |
Tue, May 1 2007 3:55 AM | Permanent Link |
"Iztok Lajovic" | Tim,
>> >> There is a much longer way to open files with EDBMgr than it is with >> DBSys. Is there any possibility to shorten necessary steps to open files? >> >> > > ElevateDB isn't file-based like DBISAM, so it really isn't possible to > open up tables with a double-click like it was in DBISAM. All of the > information regarding which tables exist, etc. is stored in the database > catalog. > Yes, I know, but given clicked table directory EDBMgr can search in catalog hierarchical structure (EDBMgr > session > databases > database > tables > selected table) how many times this particular file is found. - If there is only one hit then EDBMgr should open session, database, table and user should provide necessary information if needed as password etc. - If there are many hits then EDBMgr should open all elements in hierarchical structure while elements are common, put the user to choose appropriate element and in that manner till the table could be opened. The developers should have as short way to open the table as possible: - using DBSys one has to make three steps to open the table: select icon 'open table' > choose database (if proposed one is not appropriate) > select the table. - using EDMMgr there are nine steps: click to + to open list of sessions > select session > connect selected session > click to + to open list of databases > select then database > open the selected database > click to + to open list of tables > select the table > open selected table. This only a low level priority suggestion. Regards Iztok Lajovic |
Wed, May 2 2007 11:35 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ian,
<< Perhaps an '.ini' file or similar in the relevant data directory or somewhere could point the relevant catalog drive/directory?? >> There's a lot more to it than that when you bring in user security and required logins, etc., and frankly, I just don't want to give the impression to anyone that tables should be opened up like that. EDB just isn't designed that way. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, May 4 2007 6:45 PM | Permanent Link |
"Ian Branch" | Tim Young [Elevate Software] wrote:
> Ian, > > << Perhaps an '.ini' file or similar in the relevant data directory or > somewhere could point the relevant catalog drive/directory?? >> > > There's a lot more to it than that when you bring in user security and > required logins, etc., and frankly, I just don't want to give the impression > to anyone that tables should be opened up like that. EDB just isn't designed > that way. Hi Tim, Appreciated, however I think we, you, me and other developers, need a mechanism that will allow users to forward suspect tables for analysis/repair. How often have you, in DBISAM, requested somebody to send you the file so you can have a look? Certainly It is what I do att when the standard recovery mechanisms fail at the users site. IIUYC then there would seem att to be only one option and that would be to tie down the users environment so closely that if they need to send me a file I can plug it into my development environment and access/work on it. Anybody else got any thoughts onthe subject? Regards, Ian -- |
Mon, May 7 2007 11:59 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ian,
<< Appreciated, however I think we, you, me and other developers, need a mechanism that will allow users to forward suspect tables for analysis/repair. How often have you, in DBISAM, requested somebody to send you the file so you can have a look? Certainly It is what I do att when the standard recovery mechanisms fail at the users site. >> Sure, but that's a different issue altogether. You can send a single table's files along with the catalog file to another location and that location can still open the table. If it tries to open the other tables, they will open just fine but simply be empty. Of course, if you have foreign key constraints defined, then you might not be able to update the one table with data without possibly having other tables that complete the foreign key constraints. << IIUYC then there would seem att to be only one option and that would be to tie down the users environment so closely that if they need to send me a file I can plug it into my development environment and access/work on it. >> Nah, just do the above and then issue a CREATE DATABASE statement to hook up their database (and the directory where you copied the catalog and table files) to your current configuration. It's two steps: 1) Copy catalog and tables files to a new database directory 2) Issue the CREATE DATABASE I do it all of the time, and it's easy. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Thursday, May 23, 2024 at 07:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |