I have created an application in C# using visual studio 2010. The application uses a database and a ton of data bound controls.
I need to save a copy of the running application with what changes the user has made to a file they can double click and get their saved state back in the application.
I know I need to use a SaveFileDialog but other than I have no idea.
If all the controls are bound to data through datasets you could perhaps serialize and deserialize the underlying datasets to/from XML files in order to create some kind of "offline data file storage" feature.
Before introducing such a feature into your application you should, however, consider all the potential database synchronization issues that are potentially created though preservation of such a saved state within your application clients.
If you really only want to preserve window layout properties (such as window size, grid column width, sorted column, splitter positions etc) you have to focus on those properties only.
Here is a thread with a similar discussion
Related
After creating some collection entries in Squarespace (like Blogs, Events, Products and so on..), is it possible to access the single databases with a MySql management application?
Or is it possible to create a private MySql database and force Squarespace to use it for the collection?
I would be easier to add/edit large data..
Squarespace is very much a "design-first" platform, and the data structure (or at least, the data structure as we can access it) is heavily abstracted away in the name of a simple design process. Getting data in can indeed be difficult, and getting it out even more so. It's just not a platform friendly to data management or portability.
Furthermore, you cannot run server-side code. So unless you fetch, parse and display your date entirely client-side using JavaScript (bypassing Squrespace's collections/layout entirely), the only way to serve the data to users is to first enter it via Squarespace's back-end editing UI. Custom tools have been created that, for example, add a button in the backend editing UI that allows you to manually sync collection items/data with an external source. It basically reads your source, maps the data to the collection item creation API that the backend UI itself uses, then executes until all collection items have been added in the back-end. However, this process must be manually trigered, and continually done as needed by logging into the backend, running the syncing function, then waiting for it to finish.
Just for some background, I'm a mechanical engineer at a company and the older folks here created a database in Access 2003 which basically takes an AutoCAD Drawing or a Picture OLE and plops it in a nicely framed report with a bunch of other information. I've been making some modifications to that database, one of which is to store all OLEObjects as links to actual files in our shared network. Every new file that has been added to the database for the past week or so has been linked and the guys seem to have gotten the hang of it.
My problem at this point in time is to try and retrieve all the Objects that are embedded in the tables. I've tried Lebans OLE to Disk but that doesn't seem to work with AutoCAD Drawings (which are .dwg and .dxf files) nor does it work with "Picture".
I know this is a quite controversial topic seeing as how I'm not providing any code to start with, but I think this is too complicated for me to even begin doing and I'm in over my head. Extracting the OLEObjects by hand isn't feasible since there's over 8000 of these spread through several databases. Is there any way to automate the extraction via code?
Thanks in advance,
Rafael.
If you access the Object property of the Bound Object Frame control, for an AutoCAD Drawing this should return the AutoCAD Document Object. You can then invoke the SaveAs method of the Document object to save the file to a known location.
For example, something like:
With Me.MyBoundObjectFrame.Object
.SaveAs "Drive:\YourPath\YourDrawing.dwg"
End With
Where MyBoundObjectFrame is the name of your Bound Object Frame control.
This works successfully in my limited testing.
I'm looking to use SSRS for multi-tenant reporting and I'd like the ability to have runtime-chosen Shared Data Sources for my reports. What do I mean by this? Well, I could be flexible but I think the two most likely possibilities are (however, I'm also open to other possibilities):
The Shared Data Source is dictated by the client's authentication. In my case, the "client" is a .NET application and not the user, so if this is a viable path then I'd like to somehow have the MainDB (that's what I'm calling it) Shared Data Source selected by the Service Account that the client logs in as.
Pass the name of the Shared Data Source as a parameter and let that dictate which one to use. Given that all of my clients are "trusted players", I am comfortable with this approach. While each client will have its own representative Service Account, it's just for good measure and should not be important. So instead of just calling the data source MainDB, we could instead have Client1DB and Client2DB, etc. It's okay if a new data source means a new deployment but I need this to scale easily enough as well to ~50 different data sources over time.
Why? Because we have multiple/duplicate copies of our production application for multiple customers but we don't want to duplicate everything, just the web apps and databases. We're fine with some common "back-end" things. And for SSRS, because of how expensive licenses are (and how rarely reports are ran by our users), we really want to have just a single back-end for all of our customers (I actually have a second one on standby for manual disaster recovery situations - we don't need to be too fancy here as reports are the least important DR concern we have).
I have seen this question which points to this post but I was really hoping there was a better way than this. Because of all of those additional steps/efforts/limitations/etc, I'd rather just use PowerShell to script duplicate deployments of the reports with tweaked hardcoded data sources instead of standardizing on the steps in that post. That solution feels WAY too hacky to me and doesn't seem to scale very well at all.
I've done this a bunch of terrible ways (usually hardcoded in a dynamic script), and then I discovered its actually quite simple.
Instead of using Shared Connection, use the Embedded Connection and create your Connection string based on params (or any string manipulation code)....
So I have this fileMakerPro7 database. As my senior project, I supposed to migrate the database to a MySQL database and than give it a PHP Based interface in 3N form...
Company allow us $200 tops to spend on the project, but if I pay for something, it has to work. However, I am having trouble finding a way of migrating the database. Any suggestions?
I have found "file maker pro migrator" (http://www.fmpromigrator.com), would the trial version be enough for us? In worst case, we will start from the beginning with throwing away the whole database that company has.
I can also download fileMakerPro12 and use it for a month with trial version for free. Would I be able to convert the db by using FMP12?
I am totally lost...open to any free suggestions...
+this is a non-profit-making company I'm doing the project for
If I had to do it, I'd look at the design of the FileMaker db and create something similar in mysql. Then I would export the Filemaker data to text and import it somehow. The details depend on foreign key values and such.
The PHP interface would be done separately.
MySQL Data Conversion:
Yes, if your database is small enough, the demo version of FmPro Migrator will convert the database and also build you a PHP web application - at no cost.
Here are the limitations of the demo version:
5 fields
5 scripts
5 layouts
PHP Web Application:
Most people don't realize it, but there is a wealth of FileMaker metadata available in XML format for performing these types of conversions. This XML info is available either thru copying the layout via the clipboard or reading it from the Database Design Report XML file. I have found the clipboard data to be the most reliable source of this info.
FmPro Migrator is able to parse in the XML and convert it into the PHP web application.
Each object on a layout is represented in XML, along with style and position info. This info can be used to create form files representing the same look as the original layout. In fact, it can be difficult to see the difference between the web application and the original database if you get all of the object properties implemented. This can be helpful for situations in which companies don't want to have to retrain their employees. They want the web application to look and work the same as the original desktop application.
I have done a few of these conversions recently into the CakePHP framework. Here a few techniques I used:
Auto-Enter Calculation Fields - Stored calculation fields are calculated and stored within the model saves a record to the database.
Unstored Calculation Fields - Unstored Calculation fields are calculated in real-time within the form controller - but only for fields actually displayed on the form. This prevents unnecessarily calculating these values if they aren't being used on a form, improving performance.
Global Fields - A Global field in FileMaker is used like a global variable in programming languages. It is important to know that each FileMaker user gets there own private copy of global field data. There is no equivalent feature MySQL or other SQL database servers, but this functionality can easily be simulated using SESSION variables. Therefore each web user will still get their own private SESSION data, simulating the same functionality originally present in the FileMaker database. I structure these globals in the model data array as if they were retrieved from the model, meaning that converted scripts and fields on forms can reference them easily. Just before the record gets written into the database, the results are saved into SESSION variables for persistence.
Global Variables in Scripts - Global variables within FileMaker scripts match up very well with the use of PHP SESSION variables, if you want to implement the same functionality.
Vector Graphic Objects - FileMaker layouts frequently include rectangles, ovals and line objects. These objects can be replaced with the RafaelJS library, providing high quality resolution independent graphics.
Value Lists - Custom and Field based value lists are implemented in a centralized location within the AppController.php file. Therefore making a change to the definition of the value list within the AppController, succeeds in changing the menu automatically throughout the whole application.
I'm building medium sized business web application, data is being saved on a MySQL database.
I'm trying to think of a way of adding certain selectable "widgets" to that application (e.g. a currency widget - which will show user specified currencies when the web app is visible) but having an hard time deciding how to save the widget data and settings per user since the widgets do not have a common base.
For example, the currency widget's settings is totally different than say, a weather widget.
One will require a list of desired currencies, and one would require the weather's target location.
I thought of solving the above by keeping all the widget's settings data encoded in the "widgetData" column of a db table which will contain the userId, widgetId and widgetData.
I chose JSON as my way of encoding, and each time a user tries to load it's page, I have to decode it's settings and hand the user the desired data based on the settings.
The same is true for saving the widget's actual data which does not have a common base itself.
Hopefully I can solve this by using a NO-SQL data structure next time, but this is not the case for the current project.
The Entity Attribute Value database model would be useful very to you in this scenario.
It's much more flexible than JSON or XML or other types of formats because it works within your standard SQL data storage, albeit in a different manner.
I voted up the EAV solution because this is one of the valid reasons for using it, but don't fall in love with it. An advantage of EAV is that it is database-native to the extent that you can write queries in SQL to query it (find me all widgets missing some setting and then add it), while most engines do not have JSON support.
On the other hand, if you want/need to query within a column which contains structured data, XML is a better option than JSON (right now): http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html#function_extractvalue
If your widgets are rendered via Javascript in the browser, then your solution is perfectly fine. Your widgetData remains a JSON string, in Javascript you use JSON.parse() to turn it into an object and render it, and JSON.stringify() to turn it back into a string before posting it back to your server.