Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 9 of 9 total |
Problem converting / removing signatures from tables |
Mon, Oct 20 2014 6:36 PM | Permanent Link |
Adam H. | Hi,
I'm trying to remove the signature from tables, and am trying the method suggested in http://www.elevatesoft.com/forums?action=view&category=dbisam&id=dbisam_general&msg=58910 The problem that I have is that I can not connect to the database server (that uses a signature) without having a DBISAMEngine component in the application that uses the same signature. (If I attempt, I get the error message 'The connection to the database server at 127.0.0.1 has been lost' And once I add a DBISAMEngine component to my application, the target dataset components will use that same engine, and hence the same signature. I have the same problem in reverse. (If I attempt to connect to a non-signature database server - I get the same error if I have a DBISAM Engine component in my application with a different signature). I was just wondering has anyone ever managed to successfully remove or change a signature on database files? Reverse-SQL is unfortunately not an option as these database files contain BLOB entries. Thanks & Regards Adam. |
Tue, Oct 21 2014 2:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
Long time since I've used DBISAM but what about EXPORT & IMPORT? Roy Lambert |
Tue, Oct 21 2014 2:28 AM | Permanent Link |
Adam H. | > Long time since I've used DBISAM but what about EXPORT & IMPORT?
Thanks Roy - as in exporting to CSV and importing again. This won't work because of the binary fields that exist in the database unfortunately... |
Tue, Oct 21 2014 4:22 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
>> Long time since I've used DBISAM but what about EXPORT & IMPORT? > >Thanks Roy - as in exporting to CSV and importing again. This won't work >because of the binary fields that exist in the database unfortunately... Fallible memory says it used to for me. I stored pictures in memo fields and that was OK. Roy Lambert |
Tue, Oct 21 2014 5:56 PM | Permanent Link |
Adam H. | Hi Roy,
Thanks for that. My database unfortunately contains Memo's as well as BLOB field types. I did a quick test application and I can't even get memo's to export. (These will contain carriage returns). It seems as though people have done this before (reading through the NG's) because the common recommendation is to use DBSRVR and connect to that for one of the connections - but I can't get it to connect if there's a DBISAMEngine component on my form with a different signature, which is unfortunately precisely what I need to do. Thanks for trying to help. Cheers Adam. |
Tue, Oct 21 2014 6:41 PM | Permanent Link |
Raul Team Elevate | On 10/21/2014 5:56 PM, Adam H. wrote:
> It seems as though people have done this before (reading through the > NG's) because the common recommendation is to use DBSRVR and connect to > that for one of the connections - but I can't get it to connect if > there's a DBISAMEngine component on my form with a different signature, > which is unfortunately precisely what I need to do. I recall playing with this long time ago and trick was to read from remote and write to local. However DO NOT create the local table this way - as long as local table exists prior you should be able to open it and append records without getting its signature changed. Hence general steps like this : 1. use default engine signature and create all the local tables you need (or empty them if already exists) 2. change engine sig to your special one 3. open remote table 4. open local table 5. read from remote and append to local for all fields (i.e. insert, update fields, post) 6. repeat 3-5 for all tables Raul |
Tue, Oct 21 2014 6:50 PM | Permanent Link |
Adam H. | Hi Raul,
> I recall playing with this long time ago and trick was to read from > remote and write to local. However DO NOT create the local table this > way - as long as local table exists prior you should be able to open > it and append records without getting its signature changed. Thanks for that - this makes sense. I'll give this a go and will see what happens. Cheers Adam. |
Tue, Oct 21 2014 8:03 PM | Permanent Link |
Adam H. | Hi Raul,
Thanks for that. I've just given that a test, but have noticed something very weird. When I go to view the data in my tables, it shows no records at all - even though some of the tables are over 20mb in size. If I do a repair on the tables I'm then able to view some data, but this has me worried that I'm doing something wrong / possibly corrupting data with the move. Do you recall having to do a repair in the end to see the data as well? I'm wondering if some how the records are going across with signatures on them, even though the table doesn't have one - and it's being removed in the end with a repair? Best Regards Adam. |
Tue, Oct 21 2014 9:30 PM | Permanent Link |
Adam H. | OK – I think I may have found a successful (and much easier) approach to
remove the signatures from the engine! This does not involve using DBSRVR or remote connections at all. (Can all be done locally using just DBSYS and either a 2nd version of DBSYS running with a signature, or a small application to execute SQL with the signature) From what I can tell, it appears as though: a) A table must be created (or rebuilt?) by an application with a signature in order for that table to contain the masking signature, and b) An application created with a signature is able to view, edit, and add data to and from non-signature based tables. (Please let me know if this appears wrong). This being the case, it seems to remove signatures from tables may be as easy as creating tables with non signatures and then using a signature based application to copy data straight across. In my approach I have 2 versions of DBSYS - one standard, and one with signatures. (Although it appears I must close each instance before opening the other) 1) Using DBSYS (With signatures) - Reverse engineer the database to SQL (structure only, without data) 2) Start DBSYS (no signature) and create the tables using the SQL above. 3) Using DBSYS (With signatures) Select the directory/location of the new tables and Run the following SQL: Insert into table1 Select * from "c:\olddb\table1"; Insert into table2 Select * from "c:\olddb\table2"; Insert into table3 Select * from "c:\olddb\table3"; …etc I used the following script to Generate the SQL I would need for this: DBS.GetTableNames(DBsource.DatabaseName, Memo2.lines); for i := 0 to memo2.lines.count - 1 do memo2.lines[i] := 'Insert into '+memo2.lines[i]+ ' Select * from "c:\olddb\'+memo2.lines[i]+'";'; 5) Using DBSYS (no signatures) open a standard DBSYS application and verify that the data is there. I have no idea why the other approach that people have used worked, and mine came through with no records until a rebuild, but this approach appears to be working and stable for me. (Using DBISAM 4) I haven't done this to a live database yet - but from all tests it appears as though it should work. |
This web page was last updated on Friday, March 29, 2024 at 03:30 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |