I know that similar topics have been already raised, but maybe there are some latest news or ideas?
I want to migrate Datazen users/sources/dashboards etc. to another server (production one) in a smooth way. I was trying to do that via backup/restore, but then I couldn't access the control panel on the target server. I received an error
401 unauthorized access.
Maybe I should change something in logs/config files on the destination server?
Any ideas? I would be grateful for any help!
I dont think there is a way to do this out of the box. However, the files are quite simple XML, so can be pointed at a different server if you know PowerShell (and work out the correct values from the server).
You will have to re-point the GUID, ServerGUID and ServerURI within the sources.xml file and then rezip (as .datazen). Providing you have your hubs set up the same, Datazen will then believe the file belongs to your prod environment and you will be able to publish
Related
I've been working with visual studio in a corporate environment for a long time, where we have a central SQL Server set up to store the data for all our in-house programs.
I've been asked to work on a side job for a small company where they want a program that will share data from a database between a half dozen computers.
My first reflex is to get them to set up a small server, install a database and then connect to it like I usually do, but before I start I'm wondering if there is a better way to do it.
Part of my problem is that if this works out really well, there is a chance that the program could be used in other companies, and I don't want to have to set up a server and write a custom version with a custom connection string for each one.
It could be that I'm thinking to deeply about this, I'm just hoping that a little research ahead of time might save a lot of time down the road.
Why would you need a custom build just to change the connection string ?
Just change your app App.config - or are we missing something here ?
What is App.config in C#.NET? How to use it?
I'm using MigratorDotNet to manage Rails-style migrations for my web app. I have a workflow where, if I delete all the tables in the database, I can access an installation view that will run MigratorDotNet and create all the necessary tables.
This works locally. For some reason, when I upload my code to my Arvixe hosting, the migrations just never run. I get this odd error:
There is already an object named 'SchemaInfo' in the database.
This is odd because, prior to running migrations, I manually deleted all the tables in the database (to make sure it wasn't left over from a previous install).
My code essentially boils down to:
new Migrator.Migrator("SqlServer", connectionString.ToString(), migrationsAssembly).MigrateToLastVersion();
I've already verified by logging that the connection string is correct (production/hosting settings), and the assembly is correctly loaded (name and version).
Works locally, but not on Arvixe. How do I troubleshoot this?
This is a dark day.
It turns out (oddly) that the root cause was my hosting company used a schema other than dbo for my database. Because of this, the error message I saw (SchemaInfo already exists) was talking about their table.
My solution, unfortunately, was to rip out MigratorDotNet and go with FluentMigator instead. not only did this solve the problem, but it also gave me a more intelligible error message (one referring to the schema names).
While it doesn't seem possible to auto-set the schema, and while I need to switch the schema on my dev vs. production machine, it's still a solvable problem (and a better API, IMO). I googled, but did not find any way to change the default schema in migratordotnet.
I'm sorry for the issues that you were having. On shared hosting, unfortunately the only way that we may be able to change the schema is manually. If you are still looking for a solution that requires our assistance, please forward your ticket ID to qa .at. arvixe.com as well as arvand .at. arvixe.com and we can look into the best way to resolve this.
I'm trying to amend our content management system so it'll handle SQL database failures more gracefully. It's a bunch of ASMX pages, and a Helpers.vb file in which I've written a SQL connection tester function.
Each of the ASMX pages call the same function.
I need to create a variable I can check that's persistent and performant, otherwise I'm going to have fall back on something disasterously slow like reading a text file every time I set up a sql connection string.
I've tried using application caching, but either it doesn't work in the context of my helpers.vb file, or I've made a mess of the syntax. One problem that's already stymied some of the approaches I've found via google - I can't use 'Import System.Web.Caching' - IntelliSense doesn't show the 'Caching' part.
Has anyone got any example code that might get me up and running? Or an alternative approach?
#Mike,
Many thanks, now I'm using HttpRuntime.Cache correctly... it works!
Thanks everyone for taking the time to post :)
I've got an Access 2007 database that I developed which connects to SQL Server for the actual data storage. I used the Package Solution Wizard to create a distributable installer which included access runtime (with an ACCDE file) which I went around and installed on 15 or so PCs. Anyway, my question is, what is the best way to distribute updates to this database? Right now I'd need to go around and remove and reinstall. That's not a problem... I was just wondering if there was another way.
I've tried leaving the front end on a network share but it seems that most people suggest storing the front-end on the local machine, which makes sense. The problems I've run into when I leave it on a network share (at least with Access 2003 mdbs) is that I find myself needing to compact and repair often and I also have to kill the open sessions (user's who have the file open) when upgrading. I would imagine it could also hypothetically create an unnecessary bottleneck if the user was not on the local network.
Automating front-end distribution is trivial. It's a problem that has been solved repeatedly. Tony Toews's http://autofeupdater.com is one such solution that is extremely easy to implement and completely transparent to the end user.
We developed a vbscript 'launcher' for our access apps. That is what is linked to on the start menu of user's pcs and it does the following.
It checks a version.txt file located on a network share to see whether it contains different text to a locally stored copy
If the text is different it copies the access mdb and the new version.txt to the user's hard drive.
Finally it runs the mdb in access
In order to distribute an update to the user's pc all that is required is to change the text in version.txt on the network share.
Perhaps you can implement something similar to this
Make a batch file on the server (network drive).
Create a shortcut link to that batch file.
Copy the shortcut to User's Desktop.
When user double-clicks on shortcut, it will copy a fresh copy from network to local.
Replace old database.adp on the server drive when you update a new version.
Each user gets a copy of database.adp on their machine.
Remove Security warning when opening file from network share is here.
Batch File
#ECHO OFF
REM copy from network drive to local
xcopy "Your_Network_Drive\database.adp" "C:\User\database.adp" /Y /R /F
REM call your database file - Access 2007
"C:\Program Files\Microsoft Office\Office12\MSAccess.EXE" "C:\User\database.adp"
This is a very old post and I used the autofeupdater until it stopped working so I wrote one of my own and it has evolved over the last few years into something that I have used with many clients. It's so simple to use and there is no interface. Just an EXE and a very simple config file.
Please check it out here. I can also help with custom solutions if none of the configurations work for your needs. http://www.dafran.ca/MS-Access-Front-End-Loader.aspx
After trying all of the solutions above (not exactly these solutions but these are the common suggestions in the Access community), I developed a system entirely within Access using VBA that allows an admin DB to create and publish objects to client DBs without the need for user intervention or management of multiple DB files.
This approach has several benefits:
1. It simplifies the development process by having a dedicated environment (admin DB) for development and testing totally separate from the client DBs.
2. It simplifies the update/distribution process by allowing a developer to push out updates in real time that client DBs can implement in the background, without involving users. Can also allow devs to roll back to previous versions if desired.
3. It could be used as a kind of change management system within Access for developers who want to commit multiple changes to objects and modules and retain past changes.
4. It allows for easier user access control by allowing an admin to easily assign certain objects to specific users/roles without needing to maintain multiple versions of the DB.
I will hopefully post the code to GitHub soon, I just have to get clearance from my workplace to release it. I will edit this post to include the link when I have.
We have usually kept the Access front ends on network drives, and just put up with the need to compact and repair on a regular basis. You will probably find you need to do that even when they are installed locally, anyway.
If you must have it installed locally, there are various tools which will enable you to "push out" software updates, and the guys over on ServerFault would have more information on those. Assuming such tools aren't available, the only other option I can think of is to write a small loader program that checks the local .MDB against a master copy on the server, and re-copies it across if they are different, before then launching the MDB.
This is more of a strategy question instead of a 'help with code' question.
I have a content server and need to supply content to various shared hosting and would love to know how you guys would set this up. We would like the content to be 'cached' on the servers so that is appears as static (and to reduce the load on the content server).
Any help would be appreciated. The basic question is regarding how you would deliver and then handle the content for the shared hosting.
The usual way is to use rsync to keep the "slave" servers in sync with the "master" server. The slaves are then configured to simply display the local files. rsync will make sure that files are copied efficiently and correctly (including time stamps and permissions). It will also make sure that clients don't see partial files and it will return useful error codes, and many more issues that only someone who has been doing this for decades would think of.