-
May 5th, 2015, 01:29 AM
#1
Thread Starter
Hyperactive Member
Suggestions
hello,
looking at some suggestions here, I'm working on a desktop app which will be deployed across multiple locations. the idea was to have multiple data bases and sync data across (2 ways) to a master data base. i came to realize the complexity and performance and need to look at alternatives. considered hosting on a cloud so all users can login to a cloud client but was a pricey option.
now Im thinking about setting up one SQL data base and connect to it over TCP/IP from all locations.
any one tried this before, and what other recommendations do you have
Thanks in advance
-
May 5th, 2015, 02:51 AM
#2
Re: Suggestions
multiple data bases and sync data across (2 ways) to a master data base
That would be an absolute nightmare to manage don't whatever you do do that !!
Have you not thought about doing a Web app instead?
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
-
May 5th, 2015, 03:18 AM
#3
Re: Suggestions
i came to realize the complexity and performance
It doesn't have to be complex. Have you looked into the replication capabilities of SQL Server? they're designed to handle exactly this sort of scenario. That said, unless you've got a pressing need to split databases I would generally avoid it. Replication doesn't add a huge amount of complexity but it does add some.
Incidentally, why are you not just having all clients connect to the single master DB direct? As long as they're on a machine that can "see" your server (which can be exposed via its IP Address) then communicating with it is just a matter of supplying the right connection string and doesn't require you to start rolling your own http layers. There are some reasons (security, performance etc.) which might mean you don't want to choose this path but if we can understand your motivations we can make better suggestions.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
-
May 5th, 2015, 04:22 AM
#4
Re: Suggestions
Incidentally, why are you not just having all clients connect to the single master DB direct? As long as they're on a machine that can "see" your server (which can be exposed via its IP Address) then communicating with it is just a matter of supplying the right connection string and doesn't require you to start rolling your own http layers.
Yes you could do that, and if you have decent connectivity between your offices then i suppose it doesn't really matter if you go with a Desktop app or Intranet Web app.
Although with a Intranet app you do have the advantage of it being much easier to roll-out as you only have to update the server!!
I have to say i was assuming that you maybe had slow pipes between offices, in which case if you create a proper Web app it gets round that issue.
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
-
May 5th, 2015, 04:32 AM
#5
Re: Suggestions
Oh there's all sorts of advantages to a web app. I just wasn't sure what the user's underlying need was. I was guessing it was a security thing (some pc's outside the firewall) rather than performance but it could be either.
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
-
May 13th, 2015, 12:56 AM
#6
Thread Starter
Hyperactive Member
Re: Suggestions
Thanks for your replies, Web is the perfect answer. but i have already written a desktop app. I'm using SQL express so SQL replicationis not an option.
Ultimately, i would love to have a central database without needing to worry about syncing text files or replication.
Found this replication tool FYI http://www.symmetricds.org/ which i may consider
-
May 13th, 2015, 06:03 PM
#7
Re: Suggestions
I'd say that you are ready for version 2.0, because you have already written an app with individual databases and you run into interesting issues if you try to morph that design to synchronized databases. Version 2.0 would replace the individual databases with a client/server setup of some sort, whether web or semi-web.
Things are easier if only one person gets to edit data, but if all users can edit the same data, then you have to think about concurrency issues if you are dealing with synching, and those are never totally clean. User A can make a change at the same time as User B, and the end result is who ever comes last. You can make it so that the window of time where this will cause trouble is very small, but you can never make it nothing without going to a great deal of effort.
My usual boring signature: Nothing
-
May 14th, 2015, 02:48 AM
#8
Re: Suggestions
Web is the perfect answer. but i have already written a desktop app.
I'd say that you are ready for version 2.0
Yep i agree, you will probably spend more time trying to get your current app working (if you even do get it working) as you want then writing a version 2.0 and turning it into a Web App.
I am sure you could take most of the logic form your windows app and re-use it so it shouldn't take as long to do.
While this may not be what you want to do or hear, its probably the best advice i can give you.
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
-
May 14th, 2015, 09:56 AM
#9
Re: Suggestions
I'm not as sold on a web app, though it does sound like it might suit. If this is running over a LAN, then just having a central database with a desktop app would be fine.
My usual boring signature: Nothing
-
May 14th, 2015, 10:02 AM
#10
Re: Suggestions
If this is running over a LAN, then just having a central database with a desktop app would be fine.
I agree but i suppose i was assuming they cant do that, otherwise why don't they just do it (instead of talking about replication and the like), its simple if you have connectivity between the offices.
Maybe the OP can enlighten us?? Do you have connectivity between your offices?
Please Mark your Thread "Resolved", if the query is solved & Rate those who have helped you
-
May 15th, 2015, 02:31 AM
#11
Re: Suggestions
Web or desktop aside (I agree Web is probably better but I don't see desktop as an obstacle)...
i would love to have a central database
Then why don't you? It's not the web or desktop decision that's going to complicate your life, its the synching issue. When I suggested replication I was referring to using the built in tools with sql server. They're pretty friendly, I think, but they do require you to learn how to use them and understand the issues behind replication and how it works. If you turn to an open source tool like the one you linked to then you're probably going to find you need a much deeper understanding of that subject.
Meanwhile, to have a single centralised database you merely need network access and a connection string. It will be MUCH simpler. What's your rationale for not doing it?
The best argument against democracy is a five minute conversation with the average voter - Winston Churchill
Hadoop actually sounds more like the way they greet each other in Yorkshire - Inferrd
-
May 15th, 2015, 06:55 AM
#12
Re: Suggestions
I think a common problem is hosting the database.
If this extends beyond the borders of a single company you need the database hosted where it has visibility (i.e. not blocked by firewalls). This might or might not be a problem depending on the level to which the application is officially sanctioned and budgeted for.
Otherwise you may have to look outward at public hosting.
Then you run into the hosting company's security policies which often forbid direct database connections from outside. Add to that instability over time (host went out of business, dropped the technologies you used, raised rates and you want to move elsewhere, etc.).
Basically this begins to rule out smart clients and leaves you writing web apps, betting on some least common denominator technology suite (e.g. LAMP) that has a chance of being around tomorrow and reasonably stable over time. But at least when you are forced to move hosts you might get away with directing users to to a new "home page" URL, cheap and easy enough.
So that's where you're left: throw out everything and move to the "cheap and easy" web. Of course that might not even be viable due to the necessary sandboxing of anything browser-based... the web being the primary vector for malware, far outstripping email in modern times. Then comes the "ratcheting down of expectations" that accompanies any web application.
So it all comes down to whether the application requires or benefits from local access (for example files), whether it can all be done within a corporate LAN, and whether the application has a projected lifetime of any serious length. Casual desktop app developers have come to expect lifetimes on the 10 year scale. I doubt this is a reasonable expectation anymore, unless you have a significant long term maintenance budget for the application. The web mutates so fast now you can just give up on the idea of long lifetimes without significant ongoing investment.
-
May 19th, 2015, 10:47 AM
#13
Re: Suggestions
Originally Posted by wiss.dev
... i came to realize the complexity and performance and need to look at alternatives. considered hosting on a cloud so all users can login to a cloud client but was a pricey option.
In case it is VB6 you're using - all you have to do is, to look for a Web-Hoster which offers
"classic ASP" (not to interchange with ASP.NET) on an MS-HostSystem with an installed IIS.
That's usually about 25-30% above the prices for a Linux-based "LAMP"-hosting -
(I pay about 8 Euro per Month or so for that Windows-based WebServer, whereas a
comparable Linux-based Offer would have cost me 5-6Euro per Month - the hoster is
"1and1 germany" for those who're interested.
That's not "unaffordable" for a company I think, and such packages usually come also with
ASP.NET (in case that's preferred) and support (besides ADO/JET) also MS-SQLServer
(up to 5 DataBases with up to 2GB per DataBase is included in my package IIRC).
In case one needs a trusted certificate, to allow for encrypted https-access, this comes
usually for 3-5Euro per month extra.
As for performance...
One can test that with the following small example against the above described
MS-IIS-package (which runs a small ASP-script, to answer incoming SQL-Requests
directly with a binary serialized ADO-Recordset).
The serverside DB in question is a simple NWind.mdb, though the performance against
SQLServer (which is accessible in the same way, over serialized ADO-Rs) is comparable.
I think, 60-70msec for the entire roundtrip in case of a midsized Request (including the
visualizing-time in a VB6-DataGrid) is acceptable for the DataVolume which was delivered...
In case of the ScreenShot below (based on "Select * From Customers"),
- these were 62msec for 91 Records on 11 Columns
- a larger Select like "Select * From Orders" takes 120-150msec for 831 Records on 14 Columns
Here's the entire Code, in case you want to check this out (needs only a VB6-DataGrid
on an otherwise emtpy VB6-Form, nothing else - then Click the Form).
Code:
Option Explicit
Private Sub Form_Click()
Dim T: T = Timer
On Error GoTo 1
Set DataGrid1.DataSource = PerformNwindRequest("Select * From Customers")
Caption = "Request and visualization took: " & Format((Timer - T) *1000,"0.0msec")
1 If Err Then MsgBox Err.Description
End Sub
Function PerformNwindRequest(SQL As String) As Object
Dim Req As Object, B() As Byte
Set Req = CreateObject("Winhttp.WinHttpRequest.5.1")
Req.Open "POST", "http://vbRichClient.com/asp/ADODBTest.asp", False
Req.SetRequestHeader "Content-Type", "application/json"
Req.Send "{""DBName"": ""/data/NWind.mdb"", ""SQL"": """ & SQL & """}"
B = Req.ResponseBody
If B(0) = 123 Then Err.Raise vbObjectError, , StrConv(B, vbUnicode)
Set PerformNwindRequest = GetRsFromByteContent(B)
End Function
Function GetRsFromByteContent(Data) As Object
Dim Stream As Object
Set Stream = CreateObject("ADODB.Stream")
Stream.Type = 1 '<- 1 = adTypeBinary
Stream.Open
Stream.Write Data
Stream.Position = 0
Set GetRsFromByteContent = CreateObject("ADODB.Recordset")
GetRsFromByteContent.Open Stream
End Function
Olaf
Last edited by Schmidt; May 19th, 2015 at 10:53 AM.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|