As I start to rollout my brand spankin’ new Servoy version of my old Microsoft Access runtime application, I’m going to need to be able to convert the user’s old data to the new Postgresql database. I have found a 3rd party JDBC product (mentioned on this forum before) that allows me to connect to the Access database in the developer, and I imagine that this will also work with the Smart and Web clients. BUT, from what I understand, the Servoy runtime will only allow me one database connection, and that has to be to a Postgres database.
The alternatives if I can’t connect both databases will involve some truly ugly stuff requiring dumping data out of the old database and then importing it into the new database and reconstructing the database structure. That could potentially force me to do one more update to the Access system in order to be able to do that, or issue an extensive set of instructions to our users to do it manually. I really, really don’t want to have to do another release of the old Access system.
So, does anyone know of a 3rd party product or plugin of some kind for the Servoy runtime that would allow me to have 2 databases open within the runtime?
Any other creative thoughts on how I might accomplish this? As always, any suggestions would be appreciate.
Migrating to Postgresql shouldn’t be such a pain, I think. You can use the Copy table action to copy the structure,then some small Servoy code to copy the data (I think there is a sample somewhere on the forum). Anyway, you could also add a feature request to support more databases for our runtime client.
lvostinar:
Migrating to Postgresql shouldn’t be such a pain, I think. You can use the Copy table action to copy the structure,then some small Servoy code to copy the data (I think there is a sample somewhere on the forum). Anyway, you could also add a feature request to support more databases for our runtime client.
1 For that request. We need to sync data from a runtime laptop but because of the single DB connection we cant open the Main Db, The Log Db and the Db to sync to all at once!
Thanks for your thoughts. Maybe I’m not being clear, but I’m not understanding your answer. Can you expand on your thoughts a bit?
I’ve got the new structure in the new Postgres database already. What I need to do is be able to set up a one-time task in the runtime version of the application that can open the user’s Microsoft Access database and allow me to copy the data from that database into the Postgres database, applying a bit of logic along the way where needed. Setting up the code to manage the data movement isn’t that big a deal; it’s mostly tedious. But, as it stands I don’t think I can have both databases open at the same time to accomplish the movement of the data.
Basically, what I need to do is this…
User starts up brand new Servoy version of my application.
User tells the new version that he has existing data to move over to the new database.
User points to the Access database (or the system can locate it on its own).
App opens the Access database. Postgres database is already open. (That amounts to 2 database connections, I think).
App traverses the Access database, pulling out the data and inserting it into the Postgres database.
I don’t think I can do Step 4 from the Servoy runtime.
Thanks again for your help. I have put in a feature request as well.
Thanks for those thoughts. Yet another reason to allow multiple connections.
I think that anyone moving from a different platform to Servoy (especially ISPs like me that have specialized applications using other databases) is going to have to do a one time move from their old database platform to the new Servoy version of their software. Although my app is in Access, I think that the same would be true for those using Filemaker or FoxPro.
I understand that Servoy would like everyone to move to a SaaS application, and I’d like that, too, but I’ve got an installed base of runtime users, and not all of them are going to want to move to SaaS. So, I need to address that for them in as seamless a way as possible. Here I am trying to sell up the idea that we’re moving to the brand spankin’ new platform with lots of new capabilities, and then the first thing I have to tell them is that moving their data over from the old version is going to be a trip through hell. Eeeek!
Here’s hoping that our buddies at Servoy can help us out.
I dont see the need for multiple database connections (to the same database ?) during a Foxpro/Access/… data conversion to PostgreSql.
We have one Servoy database server for the Foxpro data and one for the Postgres data and we use them simultaneously during the conversion.
We have put the conversion in a different solution then the ‘new’ main Servoy app.
The ‘severe’ problems we now face concern the (Servoy) performance in bulk table inserts/updates which one needs in data conversion…
The Servoy time spent (in Smart Client and in the Servoy Application Server) for an insert/update compared to the corresponding database time is sky high
We have lots of time invested in optimizing the conversion in terms of Servoy code…
Just to clarify, we’re talking about 2 separate databases here. One would be a Microsoft Access database on the user’s PC, and the other would be the Postgres database which is part of the Servoy runtime, also running on the user’s PC. From what I’ve been able to find out, the Servoy runtime is currently limited to one database connection. So, you’re saying that you have 2 solutions within your runtime, they are both running at the same time, and you are able to open 2 database connections doing that? That would be interesting. I’ll have to research the Servoy runtime documentation to learn more about something like that. Ah, that brings up another question. Is there a good source for Servoy runtime documentation?
Ahh, I thought that there might be a bit of confusion there between our comments.
The Servoy Runtime is a standalone version of the Servoy environment. It is not a SaaS implementation, but rather a “mostly” single user version that is installed on the user’s PC. It includes a built-in Application Server and Smart Client, as well as a standalone copy of Postgreql. Someone please correct me if I’ve gotten the details wrong.
So, as I understand it, the runtime has some limitations…
The embedded database has to be Postgresql.
You can have one database connection.
You can have one user.
So, it’s not meant to be a SaaS implementation; it is more akin to legacy single user applications installed on PCs. Think of something like Quickbooks, for example. It installs on your PC, it is meant for use by a single person. There is an embedded data structure, and that’s what you have, no changes or alternatives. It’s not networked.
Does that help (assuming that I have the details right )?
Unfortunately multiple db connections on the runtime product isn’t supported. However that may be more of a licensing restriction rather than a technial restriction. So it leaves you with 4 options:
Use “Servoy Offline” product. Really this is just installing the app server and Db on the local machine and then the Smart Client opens from localhost. Since your running an app server, now you can have multiple connections
Make your own connection. Remember Servoy is just java, so you can write your own java code in Servoy and make your own raw jdbc connection and manually query through the connection
3 write the conversion as a service. Create a hosted solution on the server that the user can upload theur datafile to, and then it processes and they download their converted db that the runtime can read
Plead with Servoy to remove the single db restriction on the DB. I agree this sucks .
Golly, somebody who’s actually on the same continent as me
Thanks for those thoughts. #2 was brought up by my “servoy Obi-wan”, and we still might do that. I’d been considering #3 as my backup plan since I’ll have to provide the conversion utility for customers who go to the online version, anyway, and there I can have multiple connections. And, I was thinking about creating a “stub” in the online version for all of my customers, runtime or not, to create an easier path to the web version should the runtime customers decide to move over at some point. I’m just trying to avoid having my customers having to jump through any hoops to get this all done. But, if you gotta, ya gotta, I guess. I’ve got a feature request that I submitted to add this capability. I’m hoping to at least get enough information back to understand why we can only have one connection. If it’s a licensing thing, then we’re kinda stuck, but if it’s a technical thing, then I can keep whining and whining and…