Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 9 of 9 total
Thread Problem converting / removing signatures from tables
Mon, Oct 20 2014 6:36 PMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Adam


Long time since I've used DBISAM but what about EXPORT & IMPORT?

Roy Lambert
Tue, Oct 21 2014 2:28 AMPermanent 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 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate 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 PMPermanent 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. Frown

Thanks for trying to help.

Cheers

Adam.
Tue, Oct 21 2014 6:41 PMPermanent Link

Raul

Globestar Systems

Team Elevate 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. Frown

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 PMPermanent 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 PMPermanent 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 PMPermanent 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.
Image