Working with a database - database

I have an existing program for a bank account, the user can create an account then withdraw or deposit money to the account. As a transaction is processed, labels are being used to show the current information such as (Beginning Balance, Transaction Fee, Withdrawal Amount, and Ending Balance).
Now, I need to be able to keep track of the transactions being processed in a SQL database. I know how to add a database to the project and then set it up to display all of the data from the table in a gridview. This is assuming that I manually entered data into the table; however, the table should be blank when the program starts and as I process transactions, then the data should be written to the table.
How do I bind my existing fields (labels) to a datatable and send the text to the table. The book that I have is all related to just displaying the data that is already in the table and I have been through a couple of tutorial online and they seem to be about the same subject. I haven't found anything on how to do what I am looking for.
Can someone help me out here. I don't mind references to other websites that might have the answer.
Thanks,
Susan

You're going to need to go in to much more detail about your issue. Sounds like you have some fundamental set up issues with your tools, but you don't mention the tools, platform (OS), or database you are using. So, it's difficult for anyone to even point in a general direction, much less give any specific, relevant suggestions.

Related

SQL Server copy data across databases

I'm using SQL Server 2019. I have a "MasterDB" database that is exposed to GUI application.
I'm also going to have as many as 40 user database like "User1DB", "User2DB", etc. And all these user databases will have "exact same" schema and tables.
I have a requirement to copy tables data (overwriting target) from one user database (let's say "User1DB") to the other (say "User2DB"). I need to do this from within "MasterDB" database since the GUI client app going to have access to only this database. How to handle this dynamic situation? I'd prefer static SQL (in form of Stored Procedures) rather than dynamic SQL.
Any suggestion will greatly be appreciated. Thanks.
Check out this question here for transferring data from one database to another.
Aside from that, I agree with #DaleK here. There is no real reason to have a database per user if we are making the assumption that a user is someone who is logging into your frontend app.
I can somewhat understand replicating your schema per customer if you are running some multi-billion record enterprise application where you physically have so much data per customer that it makes sense to split it up, but based on your question that doesn't seem to be the case.
So, if our assumptions are correct, you just need to have a user table, where your fields might be...
UserTable
UserId
FName
LName
EmailAddress
...
Edit:
I see in the comments you are referring to "source control data" ... I suggest you study up on databases and how they're meant to be designed, implemented, and how data should be transacted. There are a ton of great articles and books out there on this with a simple Google search.
If you are looking to replicate your data for backup purposes, look into some data warehouse design principles, maybe creating a separate datastore in a different geographic region for that. The latter is a very complex subject to which I can't go over in this answer, but it sounds like that goes far beyond your current needs. My suggestion is to backtrack and hash out the needs for your application, while understanding some of the fundamentals of databases (or different methods of storing data). Implement something and then see where it can be expanded upon / refactored.
Beyond that, I can't be more detailed than the original question you posted. Hope this helps.

Understanding Data for newly hired

I have just started a new job, where I have to maintain the data warehouse, but the problem is that the company data warehouse gets data from the eautomate, and some other software, and when I look at the tables in the data warehouse, I don't understand anything. What would be the best idea for understanding all the data in the warehouse for analytic purpose? It looks like the eautomate company has build all the tables for the company and no one is here to train me how data got in there. I just felt bad for not being very productive, since its my second week at the job.
Honestly, there has to be a contact for eAutomate that set up the DB. Without having experience with eAutomate, you're handicapped.
I'd recommend getting a idea what which DBs/Tables exist, then I'd get permission to add records/modify some test data in eAutomate. Start looking in tables that seem to correspond with area of eAutomate you modified data in.
Your best bet is to get some domain knowledge before you dive into the DB.
Just my .02. Hope it helps!

Database Design for enterprise hardware stock and billing

I have to develop a database for an enterprise to manage its pc hardware and software stocks, PC breakdowns and pc assignment to users.
I'm a beginner to database design* so I'd like some advice on how to model the database properly from scratch.
I've already done some research and started something, but since you guys are experts, I'd like your take on it, please.
Details are not important, what I need is to know what tables you would make, and their relationships.
I've included a screenshot of the ERD I've come up with. Please have a look.
Here is what's I've done so far. I know it may be poorly design, keep in mind it's a first for me.
Basically, I have a list of users.
let's go for a user table.
Each user can have many pcs (but one pc for one user only).
so, PC table, with FK to users.
A PC consists of many types of identified hardware from a set list of MB, CPU, HDDs, RAM, GFX cards.
Here I made a category table for hard type (cpu, gfx, etc..)
Then make and model tables.
Finally a mode detail table to store all sorts of details like frequencies, sizes, etc..
I link those tables to a hardware table with FKs in it to have a mix giving me a piece of hardware.
---> I know there must be a way to link the table in muck better/proper/efficient manner there!
I want to be able to display the PC user/hardware given from a set list and track the hardware via its billings.
So I make a hardware stock table. I link one hardware to many hardware stocked with FK in hardware_stock table and its billing.
I can track failures/breakdowns for each PCs.
there's a failure type table. And I link it to PC via an intersecting table failure event containing FKs to pc_id and failure_type_id.
then I keep comments in a separated table linked to failure_event.
So there it is. I've not tackled the software management yet.
Basically, it's the same than hardware, I have a set list of different software and:
I want to know what's installed on the PCs.
I want to know the billings and license attached to the software stocks.
Thanks for the feedback!
I think there are two options:
Add tables "software", "publisher", "software_category"; add a link table similar to "pc_hardware".
Change 'hardware' to "component", and add 'Software' as a component category.
Option 1 adds more tables, but is more distinct; managing software licences may be easier with this approach.
Option 2 has fewer tables, but is a little harder to understand. Under this approach, a software licence could be a type of 'product warranty' (but that feels messy!)
Just out of interest, have you investigated any open-source or COTS products that do asset management and issue tracking? I have no idea if there are any products available, but you can't be the first person/enterprise to want to do this sort of thing!
Your relationships are a bit much for me to go through.
Here's how you can check your own ERD. Using pencil and index cards, write down the screen fields of your proposed system screens and the report fields of your proposed system reports.
Something like this:
Add a new PC
------------
PC name
PC network
User
...
One index card per screen and report.
If you wish, you can sketch out the appearance of the screens and reports.
Once you've done this for every screen and report you can imagine, you can map your paper screens to your paper database (ERD). If you can easily imagine (code) the select, insert, update, and delete SQL for yor paper database, then your design is good.

source code for funds transaction client-server module using Qt

I want to develop a demo mobile application using Qt that does money transactions and shows account information to the user based on a demo database created and stored in the server program. Suppose you want to pay someone. Then you enter your password, account no. and then acc. no. of the receiver and the amount to be transferred to the receiver. The same change should be reflected in the database. If the amount to be transfered is less than the balance, or a bad password is entered an error message is displayed. The database should contain say five records with fields password, name, account no., and balance.
Please do help me out as I'm new to Qt and I have read books on it to accomplish the above program but finding it difficult to code.
if you don't know how to do this I think you should use some easier technology like Java or c#, using hibernate or linq to persist to database. There are lots of tutorials on how to do this.

Best way to build a DataMart from multiple external systems?

I'm in the planning stages of building a SQL Server DataMart for mail/email/SMS contact info and history. Each piece of data is located in a different external system. Because of this, email addresses do not have account numbers and SMS phone numbers do not have email addresses, etc. In other words, there isn't a shared primary key. Some data overlaps, but there isn't much I can do except keep the most complete version when duplicates arise.
Is there a best practice for building a DataMart with this data? Would it be an acceptable practice to create a key table with a column for each external key? Then, a unique primary ID can be assigned to tie this to other DataMart tables.
Looking for ideas/suggestions on approaches I may not have yet thought of.
Thanks.
The email address or phone number itself sounds like a suitable business key. Typically a "staging" database is used to load the data from multiple sources and then assign surrogate keys and do other transformations.
Are you familiar with data warehouse methods and design patterns? If you don't have previous knowledge or experience then consider hiring some help. BI / data warehouse projects have a very high failure rate and mistakes can be expensive.
Found more information here:
http://en.wikipedia.org/wiki/Extract,_transform,_load#Dealing_with_keys
Well, with no other information to tie the disparate pieces together, your datamart is going to be pretty rudimentary. You'll be able to get the types of data (sms, email, mail), metrics for each type over time ("this week/month/quarter/year we averaged 42.5 sms texts per day, and 8000 emails per month! w00t!"). With just phone numbers and email addresses, your "other datamarts" will likely have to be phone company names, or internet domains. I guess you could link from that into some sort of geographical information (internet provider locations?), or maybe financial information for the companies. Kind of a blur if you don't already know which direction you want to head.
To be honest, this sounds like someone high-up is having a knee-jerk reaction to the "datamart" buzzword coupled with hearing something about how important communication metrics are, so they sent orders on down the chain to "get us some datamarts to run stats on all our e-mails!"
You need to figure out what it is that you or your employer is expecting to get out of this project, and then figure out if the data you're currently collecting gives you a trail to follow to that information. Right now it sounds like you're doing it backwards ("I have this data, what's it good for?"). It's entirely possible that you don't currently have the data you need, which means you'll need to buy it (who knows if you could) or start collecting it, in which case you won't have nice looking graphs and trend-lines for upper-management to look at for some time... falling right in line with the warning dportas gave you in his second paragraph ;)

Resources