![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 10 of 18 total |
![]() |
Thu, Aug 23 2007 11:31 PM | Permanent Link |
"Glynn Owen" | I want to create a small table on a local system that contains new
records for a much larger table on a remote system. What I'm thinking of doing is just to open both tables at the same time, and then append the new records of the local table into the remote table. This seems feasible, but clumsy. There will be some thousands (1 or 2) of records transferred each time, so I need something that is fast. Any recommendations for a more elegant solution? TIA, Glynn -- |
Fri, Aug 24 2007 4:27 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Glynn
SQL and a transaction Assuming the two tables have the same structure it should be a doddle eg INSERT INTO bigtable (SELECT * FROM littletable) Roy Lambert |
Fri, Aug 24 2007 4:59 AM | Permanent Link |
Luis David Cardenas | Even if they are in to different databases?
One database is local and the other is remote, i dont whink this will do it. Am i wrong? I would use remoteprocedures, saving the local table into a clientdataset, then saving the dataset into a memorystrean, then send the memorystream as a blob parameter when calling the remoteprocedure, then the remote procedure should load a clientdataset from the stream and then add all the clientdataset into the target table. |
Fri, Aug 24 2007 11:15 AM | Permanent Link |
"Glynn Owen" | Luis David Cardenas wrote:
> Even if they are in to different databases? > > One database is local and the other is remote, i dont whink this will > do it. Am i wrong? > > I would use remoteprocedures, saving the local table into a > clientdataset, then saving the dataset into a memorystrean, then send > the memorystream as a blob parameter when calling the > remoteprocedure, then the remote procedure should load a > clientdataset from the stream and then add all the clientdataset into > the target table. This is essentially what happens now, except that the transport being used is an Indy TcpIPServer. Thanks for the tip. I've never used remote procedures with DBISAM, but they seem like an elegant solution to this problem. Regards, Glynn -- |
Fri, Aug 24 2007 12:41 PM | Permanent Link |
"Glynn Owen" | Roy Lambert wrote:
> Glynn > > > SQL and a transaction > > Assuming the two tables have the same structure it should be a doddle > eg > > INSERT INTO bigtable (SELECT * FROM littletable) > > > Roy Lambert Thanks for the thought, but I think this is restricted to tables from the same database. Regards, Glynn -- |
Fri, Aug 24 2007 2:35 PM | Permanent Link |
David Cardenas | RemoteProcedures are easy to implement, the only catch is that you need to code them
in the server, so you need a custom compiled version of the dbisam server, so, you need the source code of the server. other than that is this forum you can find some working samples. "Glynn Owen" <glynnMowenREMOVE@hotmail.comDELETE> wrote: Luis David Cardenas wrote: > Even if they are in to different databases? > > One database is local and the other is remote, i dont whink this will > do it. Am i wrong? > > I would use remoteprocedures, saving the local table into a > clientdataset, then saving the dataset into a memorystrean, then send > the memorystream as a blob parameter when calling the > remoteprocedure, then the remote procedure should load a > clientdataset from the stream and then add all the clientdataset into > the target table. This is essentially what happens now, except that the transport being used is an Indy TcpIPServer. Thanks for the tip. I've never used remote procedures with DBISAM, but they seem like an elegant solution to this problem. Regards, Glynn -- |
Fri, Aug 24 2007 3:13 PM | Permanent Link |
"Jeff Cook" | Glynn Owen wrote:
> Roy Lambert wrote: > > > Glynn > > > > > > SQL and a transaction > > > > Assuming the two tables have the same structure it should be a > > doddle eg > > > > INSERT INTO bigtable (SELECT * FROM littletable) > > > > > > Roy Lambert > > Thanks for the thought, but I think this is restricted to tables from > the same database. > > Regards, > Glynn If that's true (is it?), then making the "littletable" a memory table should solve problem. No mssing around with remote procedures and source changes to the server + works in C/S and file server modes. Much more elegant. -- Jeff Cook Aspect Systems Ltd www.aspect.co.nz + Joan and Jeff Cook The Cooks Oasis www.cookislandsoasis.com |
Fri, Aug 24 2007 4:02 PM | Permanent Link |
"Glynn Owen" | David Cardenas wrote:
> RemoteProcedures are easy to implement, the only catch is that you > need to code them in the server, so you need a custom compiled > version of the dbisam server, so, you need the source code of the > server. other than that is this forum you can find some working > samples. > > > "Glynn Owen" <glynnMowenREMOVE@hotmail.comDELETE> wrote: > > Luis David Cardenas wrote: > > > Even if they are in to different databases? > > > > One database is local and the other is remote, i dont whink this > > will do it. Am i wrong? > > > > I would use remoteprocedures, saving the local table into a > > clientdataset, then saving the dataset into a memorystrean, then > > send the memorystream as a blob parameter when calling the > > remoteprocedure, then the remote procedure should load a > > clientdataset from the stream and then add all the clientdataset > > into the target table. > > This is essentially what happens now, except that the transport being > used is an Indy TcpIPServer. > > Thanks for the tip. I've never used remote procedures with DBISAM, but > they seem like an elegant solution to this problem. > > Regards, > Glynn Can't I set up a DBISAMEngine component as my server, locate it on the remote machine, and then address it from other sites? Is that what you mean by "Access to the Server", or is there more to it than that? Regards, Glynn -- |
Fri, Aug 24 2007 4:06 PM | Permanent Link |
"Glynn Owen" | Jeff Cook wrote:
> Glynn Owen wrote: > > > Roy Lambert wrote: > > > > > Glynn > > > > > > > > > SQL and a transaction > > > > > > Assuming the two tables have the same structure it should be a > > > doddle eg > > > > > > INSERT INTO bigtable (SELECT * FROM littletable) > > > > > > > > > Roy Lambert > > > > Thanks for the thought, but I think this is restricted to tables > > from the same database. > > > > Regards, > > Glynn > > If that's true (is it?), then making the "littletable" a memory table > should solve problem. No mssing around with remote procedures and > source changes to the server + works in C/S and file server modes. > Much more elegant. I can't say for sure, but it seems unlikely to me, since the "littletable" doesn't exist within the context of the "bigtable". I have seen SQL that allows for qualifiers to table tokens, but I don't know if DBISAM can do that. Also, what do you mean by a "memory table"? Are you referring to a TClientDataset, or something else? Thanks, Glynn -- |
Fri, Aug 24 2007 4:52 PM | Permanent Link |
David Cardenas | >Can't I set up a DBISAMEngine component as my server, locate it on the >remote machine, and then address it from other sites? Is that what you >mean by "Access to the Server", or is there more to it than that? Well, actually you can do it. I prefer messing with a custom dbsrvr ![]() |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Wednesday, August 14, 2024 at 07:31 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |